Enable filters parameter with flattened agent-friendly schema

[themightychris]

Summary

This PR enables the filters parameter for search endpoints with a properly structured schema that's optimized for LLM agents.

Previously, the filters parameter was explicitly excluded from the MCP tool schema with TODO comments. This change:

• Removes the filter exclusion guards
• Adds a flattened schema following the existing PropertyValue pattern in the codebase
• Provides clear property descriptions and enums for filter conditions

Approach

Rather than exposing the complex recursive FilterExpression with 12 oneOf variants, we flatten it into a single object with all possible fields as optional properties. This mirrors how the codebase already handles PropertyValue schemas and is much easier for LLMs to understand and use correctly.

Schema Structure

{
  "operator": "and" | "or",
  "conditions": [{
    "property_key": "done",
    "condition": "eq",
    "checkbox": false
  }],
  "filters": [/* nested expressions */]
}

Tested Working

• Checkbox filters: {"conditions": [{"property_key": "done", "condition": "eq", "checkbox": false}]}
• Existence filters: {"conditions": [{"property_key": "links", "condition": "nempty"}]}

Note

Object ID filters (condition: "in"/"all" with objects array) return 400 from the API - this appears to be an API-side limitation, not related to this MCP change.

🤖 Generated with Claude Code

[Tsopic]

Thanks for this — I rechecked it against current main (v1.2.9) and a live Anytype 2025-11-08 OpenAPI document.

Current MCP now keeps all tools registered (50 tools locally, including create/update/search), but FilterExpression is still converted to {} and filters is explicitly removed from both space/global search inputs, so this PR remains the right fix.

Before merge, could this be rebased or cherry-picked onto current main? The old PR branch no longer has a local merge base with the rewritten current history. Please also:

1. Add the missing files: string[] value field from FilesFilterItem.
2. Add parser regression tests for both search-space and search-global, the full live condition enum (eq, ne, gt, gte, lt, lte, contains, ncontains, in, nin, all, empty, nempty), all value fields, and nested filters.
3. Regenerate scripts/tools.json from the current spec.

I would keep generic $defs handling out of this PR: current live generated tool schemas contain zero $ref nodes, so #24 is not a dependency for this flattened filter fix.

[themightychris]

Thanks @Tsopic — all four points addressed:

1. Rebased. The branch now sits directly on top of current main (a86c918), so it applies cleanly against the rewritten history.
2. Added files: string[]. This was the one FilterItem variant (FilesFilterItem) missing from the flattened schema — now present on each condition alongside objects.
3. Parser regression tests (src/openapi/__tests__/parser-filters.test.ts, new). Loads the checked-in 2025-11-08 spec and pins the flattened schema for both search-space and search-global: the and/or operator enum, the full 13-value condition enum (eq, ne, gt, gte, lt, lte, empty, nempty, in, nin, contains, ncontains, all), all type-specific value fields, required keys, and nested filters. 82/82 tests pass.
4. Regenerated scripts/tools.json from the current spec — the only resulting delta is the new files field in both search tools.

Agreed on keeping generic $defs/$ref handling (#24) out of this PR — the flattened schema emits zero $ref nodes, so it's independent.