Skip to main content
If an ActionKit call returns 200 but the filter, limit, or field you passed did nothing, Run Tool likely ignored those keys. Extra or misspelled parameters are not rejected. The action runs with whatever documented fields were actually present, which for a search is often the unfiltered default. Compare your parameters object to the tool schema from List Tools or the Tools Reference. Drop keys that are not in that schema. There is no schemaEnforcement query parameter on Run Tool.

​
Symptoms

  • The request succeeds. You do not get a validation error naming the bad fields.
  • A search or list action returns a large, unfiltered set. Filters you thought you sent (assignee_id, status_filter, a similar invented name) have no effect.
  • An LLM is calling a generic run_integration_action (or passing List Tools schemas loosely) and invents parameter names that look reasonable.
  • Task History shows a successful ActionKit run. For successful runs, the dashboard does not show the provider response body, so the only clue is that the result set does not match the intent.
You will not see a 4xx that lists unknown properties.

​
Cause

Run Tool takes tool plus a parameters object. Each tool’s documented fields are listed on its Tools Reference page and in the JSON Schema from List Tools. Run Tool does not currently fail the call when parameters contains keys outside that schema. Unknown keys are dropped. Missing optional keys use the tool’s defaults. The HTTP response is still success, so an agent or a thin wrapper has no error to feed back to the model. That is especially visible on filter actions: if the real filter field is absent, the action searches with no filter. Worked example: Filter Issues (JIRA_FILTER_ISSUES) documents jqlQuery (DNF object with operator and conditions) and limit. This body is accepted and does not filter:
None of those keys are on the schema. jqlQuery is omitted, so you get the default issue list. Use jqlQuery for assignee and status, and limit (not max_results) to cap the page. For a raw JQL string, use Search By JQL (JIRA_SEARCH_BY_JQL) instead. The same pattern applies to every tool: the names in parameters must match that tool’s schema, not a guess, not another product’s API, and not a sibling tool’s fields.

​
Fix

​
1. Diff the payload against the schema

Pull the tool from List Tools (format=json_schema) or open its Tools Reference page. Every key under parameters must appear there. If you wrap many tools in one generic function, validate the model’s arguments against that tool’s schema before calling Run Tool. Return the validator’s errors to the model. ActionKit will not do that for you.

​
2. Put filters in the documented filter field

Do not invent assignee_id, status_filter, or similar. Use the filter parameter the schema names (jqlQuery, filterFormula, a COQL query on a dedicated query tool, and so on).

​
3. Cap result size with the documented limit field

Large unfiltered responses are a consequence of a no-op filter, not a separate ActionKit bug. Use the tool’s limit / paginationParameters fields, and handle large payloads in your app if the default page is still too big.

​
Prevention

  • Pass List Tools JSON Schema into the model as the tool definition, as in ActionKit for tool calling, instead of a single unconstrained run_integration_action.
  • Reject extra properties in your own validator (additionalProperties: false on the tool’s parameters schema).
  • Treat HTTP 200 as “the tool ran,” not “every key you sent was applied.”

​
Still having issues?

Send the exact Run Tool body (tool name and parameters), the tool schema you used, and a short description of what you expected vs what came back. If the keys match the schema and the provider still ignores the filter, that is a different problem than this one.