Noticing two things when using the Metabase toolkit: 1. METABASE_POST_API_CARD is blocked by proxy-execute. We don't have proxy-execute enabled on our Composio key. Using that tool returns a "403: Proxy execute is not enabled for this API key. Create a new scoped API key with proxy execute functionality enabled from project settings ". I've never seen this before and what's confusing is that other write actions on the same connected account work fine and clearly don't need proxy-execute. Is this expected behavior? 2. METABASE_PUT_API_CARD_ID is getting rejected with a "400: Invalid query: missing or invalid Database ID (:database)". We're sending the database ID as the integer 34, but by the time the request reaches Metabase it's being converted to an invalid float 34.0. I appreciate the help!

Hi Brian, Thanks for flagging this, and for the detailed examples. The

METABASE_PUT_API_CARD_ID

issue looks valid to us:

database: 34

becoming

34.0

points to a serialization/coercion issue before the request reaches Metabase. The

METABASE_POST_API_CARD

proxy-execute error also looks suspicious, since that tool should not normally require Proxy Execute. Could you send us either the debugging log IDs / request IDs for one failed call from each tool, or the debugging info from your project settings? Either one should let us tie this to the exact project and trace where the request is being routed/coerced.

Tried this out again today. Issue #2 appears resolved. Issue #1, I cannot provide a log ID, presumably because the call is blocked before it is made? Here's the payload and response: Input { path:"/tasks/submit/integration:metabase:post-api-card:test-post-card-2.json", content:"{"name": "Test Card", "display": "table", "dataset_query": {}}" } Output ▶ Execution failed for /tasks/submit/integration:metabase:post-api-card:test-post-card-2.json: Failed to proxy-execute metabase action METABASE_POST_API_CARD: Error: 403 {"error":{"message":"Proxy execute is not enabled for this API key. Create a new scoped API key with proxy execute functionality enabled from project settings.","code":2812,"slug":"ExternalProxy_OrgNotAllowed","status":403,"request_id":"12b13384-2446-4a29-95cd-370067ab566f","suggested_fix":"Proxy execute is not enabled for this API key. Create a new scoped API key with proxy execute functionality enabled from project settings."}}

Hey @BrianSalHal, Good to know Issue #2 is resolved and thanks for sharing the request ID. We checked the activity and found a few Proxy Execute attempts, all of which were blocked because the current Project API key does not have Proxy Execute enabled. Could you create a new scoped Project API key with Proxy Execute enabled, retry the request, and let us know if that resolves it?

@Abhishek we don't really want Proxy Execute enabled. Can you help me understand why a standard tool in a toolkit would need proxy execute?

If i'm not mistaken the request

12b13384-2446-4a29-95cd-370067ab566f

explicitly hit

POST /api/v3.1/tools/execute/proxy

Ah, after further review, we started routing that tool to proxy execute a couple months back because it was failing under execute. When our agent created a Metabase card via METABASE_POST_API_CARD on the normal execute path, the request reached Metabase with an empty dataset_query: {} and fails with null value in column "database_id". Our current guess is that it's tied to the schema declaring dataset_query (and similar fields) as {"type":"object","additionalProperties":true} with no nested properties, and that your validator strips nested keys there — but we're not certain that's the cause. Can you tell us what's actually happening: is it the schema/validator, something else in the execute pipeline, or is our analysis off? And what's the recommended fix so plain execute works without the proxy?

Your analysis is essentially correct.

dataset_query

is currently exposed as an unstructured object, so structured tool callers can produce

{}

without the required nested fields. This is a schema issue on our side, not a requirement to use Proxy Execute. If you control the execution arguments, the supported workaround is to pass the complete nested object explicitly through normal tool execution:

{
  "name": "Test Card",
  "display": "table",
  "dataset_query": {
    "database": 34,
    "type": "native",
    "native": {
      "query": "SELECT 1"
    }
  }
}

We’ve logged the schema fix with engineering. If your model generates arguments solely from the current tool schema, there isn’t a reliable schema-driven workaround until that is fixed.