> ## Documentation Index
> Fetch the complete documentation index at: https://docs.useparagon.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ActionKit accepts unknown parameters and ignores them

> Run Tool returns 200 and silently drops keys that aren't on the tool schema, which can leave a search unfiltered.

Breadcrumb

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](https://docs.useparagon.com/actionkit/api-reference/list-tools.md) 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](https://docs.useparagon.com/actionkit/api-reference/run-tool.md) 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`)](https://docs.useparagon.com/actionkit/integrations/jira/JIRA_FILTER_ISSUES) documents `jqlQuery` (DNF object with `operator` and `conditions`) and `limit`. This body is accepted and does not filter:

```json theme={null}
{
  "action": "JIRA_FILTER_ISSUES",
  "parameters": {
    "assignee_id": "me",
    "max_results": 50,
    "status_filter": "in_progress"
  }
}
```

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`)](https://docs.useparagon.com/actionkit/integrations/jira/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.

| What you pass | What Run Tool does |
| - | - |
| Only keys from the tool schema | Those fields are applied |
| Extra keys that are not on the schema | Call still succeeds; extra keys are ignored |
| Wrong name for a real field (`max_results` instead of `limit`) | The real field is treated as absent (default or unfiltered) |
| Required field missing | Follows that tool's required list; this is separate from extra-key handling |

## 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](https://docs.useparagon.com/actionkit/actionkit-for-tool-calling.md), 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.

## Related articles

* [Run Tool](https://docs.useparagon.com/actionkit/api-reference/run-tool.md)
* [List Tools](https://docs.useparagon.com/actionkit/api-reference/list-tools.md)
* [ActionKit for tool calling](https://docs.useparagon.com/actionkit/actionkit-for-tool-calling.md)
* [Schema formats](https://docs.useparagon.com/actionkit/schema-formats.md)
* [JIRA\_FILTER\_ISSUES](https://docs.useparagon.com/actionkit/integrations/jira/JIRA_FILTER_ISSUES.md)