Clean, filter and reshape JSON rows in one call: 26 transforms, 25 filters, sort, dedupe, limit.
Scored across 2 tools
The two tools have entirely non-overlapping roles: list_capabilities is a free introspection call that processes no data, while process_rows does the actual pipeline work. There is no scenario where an agent would confuse one for the other.
Both names follow the same verb_noun snake_case convention (list_capabilities, process_rows). The verbs accurately reflect each tool's action, and the pattern is fully predictable.
Two tools is thin for the surface, though the design is deliberate: one discovery tool plus one workhorse that bundles transform, filter, sort, dedupe, and limit. It is borderline rather than mismatched, since each tool clearly earns its place.
The domain of row filtering and transformation is well covered by process_rows, which handles renaming, dropping, casting, arithmetic, regex extraction, filtering, sorting, dedupe, and limiting, with a removal summary and a capabilities endpoint for discovery. Minor gaps exist (no dry-run/preview mode or schema inspection beyond the static capabilities list), but agents can work around them.
Returns every filter operator and transform operation this server supports, the order the pipeline runs in, and the maximum rows per call. Call this first if you are unsure what is available. Free, processes no data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose two behavioral traits: 'Free' (no cost) and 'processes no data' (read-only, no side effects on the dataset). That is meaningful disclosure beyond the empty schema. It stops short of describing response shape or size limits, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: what it returns, when to call it, and what calling it costs. The payload enumeration is front-loaded ahead of the usage hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must summarize the return value, and it does so concretely by listing the four categories of information returned. Nothing an agent needs to decide whether and how to call this zero-arg discovery tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to document; baseline 4 applies. The description correctly does not invent parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('returns every filter operator and transform operation this server supports') and enumerates the concrete payload: operators, operations, pipeline execution order, and the per-call row limit. This clearly separates it from the only sibling, process_rows, which is the thing being described rather than the thing describing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this first if you are unsure what is available' gives an explicit triggering condition for use. It does not name the alternative tool or state a when-not condition, but the 'unsure' framing makes the routing decision obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cleans a list of JSON rows in one call: transforms each row, filters out the rows you do not want, then optionally sorts, de-duplicates and limits them. Returns the kept rows plus a summary of exactly what was removed and why. Use it to reshape scraped or API data before passing it on: rename and drop fields, cast strings to numbers, compute new fields with arithmetic, extract with regex, then keep only the rows that match your rules. Transforms run before filters, so you can filter on a field you just created.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | The rows to process. Each row is a JSON object. Keys may differ between rows. | |
| limit | No | Return at most this many rows. | |
| offset | No | Skip this many rows after filtering and sorting. | |
| sortBy | No | Sort the kept rows, for example [{"field":"price","direction":"desc"}]. | |
| filters | No | Conditions a row must satisfy to be kept, for example {"field":"country","operator":"equals","value":"UK"} or {"field":"price","operator":"greaterThan","value":100}. Dot paths like "address.city" work. Call list_capabilities for all 25 operators. | |
| distinctBy | No | Keep only the first row for each combination of these fields. Applied after sorting, so sorting first lets you keep the newest row per key. | |
| transforms | No | Transform steps applied to every row, in order. Each step is an object with an "op" key, for example {"op":"cast","field":"price","to":"number"} or {"op":"compute","field":"total","expression":"price * qty"} or {"op":"rename","from":"e_mail","to":"email"}. Call list_capabilities for all 26 operations. | |
| lenientNumbers | No | On by default: values like "$1,234.50", "49 USD" and "12%" are read as numbers. Set false to require real numeric values. | |
| filterCombineMode | No | Whether a row must match every filter (AND, the default) or any one of them (OR). | |
| caseSensitiveFilters | No | Text comparisons are case-insensitive by default. Set true to make them exact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the burden and does well: it defines the execution order (transforms → filters → optional sort/dedupe/limit), states that a removal summary is returned, and discloses defaults (lenientNumbers on, AND default, case-insensitive default). It omits permission/rate-limit/mutation-reversibility context, but the tool is a pure in-memory computation with nothing destructive to warn about.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what the tool does, then a concrete usage recipe, then the critical ordering rule. No redundancy with the schema and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter, mutation-free, single-sibling tool with a fully documented schema and no output schema, the description covers purpose, pipeline order, and return shape. It could mention where the output summary lives or a size/complexity caveat, but nothing essential to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly, including operator and op examples. The description still adds pipeline-ordering semantics (transforms before filters, dedupe after sorting, offset applied after filtering and sorting) that the schema alone does not make explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Cleans a list of JSON rows'), enumerates the pipeline stages (transform, filter, sort, dedupe, limit), and names the return ('kept rows plus a summary of exactly what was removed and why'). It is the only data-processing tool among the siblings, so differentiation is trivial but the scope statement is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context ('reshape scraped or API data before passing it on') and named use cases (rename/drop, cast, compute, regex extract, rule filtering). It also states an ordering rule ('Transforms run before filters'). No explicit when-not or alternative is offered, but no real alternative exists beyond list_capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_capabilitiesprocess_rowsStandardize, reshape, and normalize messy data — CSV, Excel, Parquet, S3, databases.
Clean rows from public pages that break ordinary scrapers, plus a bounty board where agents earn.
SEC EDGAR as clean JSON: Form 4 insider trades, 8-Ks, 13F holdings, 13D/G >5% stakes, fundamentals.
300+ deterministic data utilities for AI agents: validate, normalize, parse, match, redact.
