Anchor MCP

Overview Schema Source Related Servers Discussions Admin

search_records

Search records by full-text content, title, typed field conditions, or linked relations, returning sorted, paginated previews with match snippets.

Instructions

Search active records. text = full-text search over titles AND every stored data value at any depth (not key names): all words must match, case/accent-insensitive, as prefixes ('interv' finds 'interview'); best match first with a match_snippet. Use text when the user describes something by content rather than exact title. query = case-insensitive literal title substring. AND top-level filters use canonical JSON equality (null differs from missing; nested values compare in full). All three combine with AND, as do: where = [{field, op, value}] typed conditions. field is a LIST of keys (["offer","ctc"]), op is eq ne gt gte lt lte between in contains exists missing. A condition matches only when the stored type matches the operand type: 38 never matches "38" or "38 LPA". Dates compare correctly when stored as ISO 8601 strings (2026-10-03). linked_to = {record_id, relationship_types?, direction?}: only records linked to that record; direction is from the matched record's side (outgoing = it is the source). order_by = {field, type: "number"|"string", direction?}: sort by a field; records lacking the field or holding another type are EXCLUDED, not sorted last. Not combinable with text. Return 1–100 bounded previews with an opaque cursor. Zero matches does not establish nonexistence. Reuse the same search parameters with the next cursor.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`text`	No
`limit`	No
`query`	No
`where`	No
`cursor`	No
`filters`	No
`order_by`	No
`linked_to`	No
`collection_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 19, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, and it delivers: typed equality semantics (38 never matches "38"), canonical JSON equality where null differs from missing, order_by exclusion behavior, cursor pagination, and the warning that zero matches does not establish nonexistence. These are non-obvious traits an agent must know before calling the tool correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place; it uses compact labeled sections for each parameter and front-loads the core purpose. There is no repetition of schema names or filler, and the dense formatting makes complex semantics scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter search tool with no annotations, this is a remarkably thorough description covering matching rules, type strictness, date handling, sorting, pagination, and cursor reuse. The main gap is collection_id, which is not explained at all, and the limit parameter is left implicit, so a fully self-sufficient agent would still have small uncertainties.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does for most parameters: text, query, where, linked_to, order_by, filters, and cursor are all explained in meaningful detail. However, collection_id is never mentioned, and limit semantics are only implied via the 1–100 preview bound, leaving two parameters underdocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Search active records', a specific verb plus resource, and immediately scopes the operation to active records only. It then precisely differentiates the text and query modes, so an agent knows exactly what the tool does. The purpose is unambiguous even though no sibling search tool exists to distinguish it from.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit selection rule: 'Use text when the user describes something by content rather than exact title', which is exactly the kind of when-to-use guidance agents need. It also states that order_by is not combinable with text. It does not compare this tool against sibling alternatives, so it stops just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.