Validate and clean CSV before import. Find duplicates, missing values and invalid dates with row-level reports. Apply only the cleanup you request; files are not retained. Run view_csv_demo free without a key. Custom CSV: EUR 9 for 100 operations, valid 90 days, no subscription. Setup: https://check.orvel.dev/docs/
Scored across 10 tools
Core paid tools target distinct stages: profiling (inspect_table), transformation (prepare_table), validation (validate_csv), cleanup (clean_csv), and joining (reconcile_tables). clean_csv also performs validation, which slightly overlaps with validate_csv, and the example/demo tools mirror real tools, but the descriptions clearly distinguish paid vs free and action boundaries.
All tool names use snake_case with a verb_noun pattern: clean_csv, get_csv_example, inspect_table, prepare_table, reconcile_tables, validate_csv, view_csv_demo. Minor singular/plural variation exists (table vs tables) but no mixed conventions or vague verb styles.
Ten tools is well-scoped for a CSV import-check service, covering core paid operations plus free examples, demos, and usage lookup. Each tool has a clear role and none feels redundant or excessive.
The surface covers profiling, transformation, validation, cleanup, two-table reconciliation, examples, demos, and usage checks, which is strong lifecycle coverage for stateless CSV import checking. Minor gaps like batch processing or schema/recipe management are not essential for the stated purpose.
Apply only requested column renames and transformations, then validate the output against schema. Cleanup column names refer to the original headers; schema names refer to the renamed output. Transformations run in listed order. decimal_comma changes only plain numbers such as 12,50; ambiguous grouping stays unchanged. No records or columns are removed. Returned csv_text is UTF-8-compatible with CRLF record endings. One paid operation includes cleanup and validation. Spreadsheet-safe escaping is opt-in and may make numeric negative cells fail numeric validation; inspect the final report before import.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes | ||
| cleanup | Yes | ||
| csv_text | Yes | ||
| delimiter | No | , | |
| request_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: no records or columns are removed, output is UTF-8 with CRLF endings, it is a single paid operation, and spreadsheet_safe may break numeric validation. The 'no columns removed' claim is consistent with destructiveHint=false. It stops short of describing failure behavior (e.g., what happens if validation fails).
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?
Six tight sentences, each carrying distinct information; the core operation is front-loaded in sentence one and the risk caveat is deferred to the end where it belongs. Slightly dense, but no sentence is 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?
With no output schema, the description usefully characterizes the return (csv_text, UTF-8, CRLF) and notes a final report. It omits error/validation-failure behavior and does not cover two top-level parameters, but for a stateless transform tool the picture is nearly complete.
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?
Top-level schema coverage is 0%, so the description must compensate. It does for the hardest semantics: 'Cleanup column names refer to the original headers; schema names refer to the renamed output' disambiguates the two objects, and the decimal_comma note clarifies that action. It says nothing about the delimiter or request_id parameters, leaving those to the enum/defaults.
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?
The opening sentence names a specific compound action — apply only the requested column renames/transformations, then validate the output against schema. This distinguishes it from the validate_csv sibling, which only validates. An agent can tell what this tool does and how it differs from its siblings without opening the schema.
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?
The description says transformations run 'in listed order' and that cleanup names refer to original headers while schema names refer to renamed output, which implies correct usage. However, it never states when to prefer this tool over validate_csv or get_csv_usage, nor any prerequisite/exclusion conditions. Usage is implied rather than specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a fixed synthetic CSV and its column schema. Free, no key or quota. Copy the structure, then supply your own CSV to validate_csv.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description earns credit by adding cost/auth context not present in annotations: 'Free, no key or quota', plus the deterministic 'fixed synthetic' nature of the payload.
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, front-loaded with the return value, then cost, then the follow-on action. 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?
There is no output schema, and the description does say what comes back (CSV plus column schema). It omits return-format specifics such as delimiter or how the schema is represented, but for a zero-parameter example tool this is largely complete.
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 for the description to disambiguate; baseline is 4. No misleading parameter claims are made.
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 and resource: returns a fixed synthetic CSV plus its column schema. It also implicitly distinguishes itself from siblings by pointing at validate_csv as the place to send real data, whereas this tool provides the reference example.
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 a concrete workflow: copy the structure, then supply your own CSV to validate_csv. That names the alternative and the condition for moving on, though it never says when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read remaining operations and expiry for the API key supplied in the Authorization header. Does not consume credit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds the genuinely useful behavioral fact that the call does not consume credit, but says nothing about invalid/missing key behavior or any rate limits.
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?
Two short sentences, front-loaded with the operation and result, followed by a single high-value constraint. 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 parameterless read with no output schema, the description covers the resource read and the auth source. It does reasonably cover returns by naming 'remaining operations and expiry', though it does not describe response formatting.
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?
Zero parameters, so the schema cannot carry semantic load. The description compensates by stating the credential comes from the Authorization header rather than a parameter, which is the key input detail an agent needs.
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 (read) and resource (remaining operations and expiry), and identifies the subject as the API key from the Authorization header. This clearly separates it from the sibling CSV-content tools (clean_csv, validate_csv), though it doesn't explicitly name them.
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?
Usage is implied by the purpose — check quota before spending operations — and the note 'Does not consume credit' hints at when it is safe to call. However, there is no explicit when-to-use or when-not-to-use guidance relative to the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return fixed synthetic left/right tables and a reusable join recipe. No arguments, key or credit. Copy the structure for reconcile_tables; mode controls which unmatched rows appear in output.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is fully covered elsewhere. The description adds two genuinely useful facts beyond the annotations: there are 'No arguments' and the call costs 'no credit', plus that the data is 'fixed synthetic', implying deterministic output. It stops short of describing the shape of the returned recipe.
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 with the core deliverable front-loaded, and no filler. The 'mode' clause is the one line that neither earns clarity nor fits the no-argument reality, keeping it from a 5.
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 carries the burden of explaining what comes back; it names the return ('fixed synthetic left/right tables and a reusable join recipe') but not the actual structure an agent would copy. Combined with the unexplained 'mode' reference, an agent has enough to call it but not a fully coherent picture of the output.
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?
Zero parameters means the baseline is 4, but the description creates confusion rather than clarity: it first asserts 'No arguments', then says 'mode controls which unmatched rows appear in output'. Since the schema exposes no mode property, this sentence reads as internally inconsistent and risks misleading the agent about whether a mode argument exists. That ambiguity pulls the score below the 0-param baseline.
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?
The description states a specific verb and resource: it returns 'fixed synthetic left/right tables and a reusable join recipe', which is far more concrete than the title alone and tells the agent this is a template-producing tool. It distinguishes itself from the mutation-oriented reconcile_tables it feeds, though it does not explicitly contrast with its closest sibling, get_csv_example.
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?
'Copy the structure for reconcile_tables' implies the intended workflow (grab the example, then model a real join on it), which is useful routing context. However, it never states when to choose this over get_csv_example or view_table_demo, and gives no exclusions, so usage is only implied rather than specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Profile a CSV or explicit string table before writing a recipe. Return empty, distinct and duplicate-value counts per column and complete formula warnings; no schema or business validity is inferred. Supply CSV OR columns/rows, never both. JSON numbers must be encoded as strings so identifiers keep leading zeros. One paid operation; no content retained. Reuse request_id only for identical input.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | ||
| request_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses the cost model ('One paid operation'), data handling ('no content retained'), idempotency semantics ('Reuse request_id only for identical input'), and the limits of inference ('no schema or business validity is inferred'). This explains the non-read-only annotation and conveys return semantics despite the absence of an output schema.
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?
Six short sentences, front-loaded with the purpose and output before constraints, with no filler. Each sentence adds a distinct operational fact (output shape, input exclusivity, encoding rule, cost/retention, idempotency).
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 two-parameter tool with no output schema and no annotation detail beyond flags, the description supplies the return shape, cost, retention, idempotency, and input XOR rule. An agent has everything needed to call it correctly; only the delimiter's meaning is left to the enum.
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?
With 0% schema description coverage, the description carries the burden and does well: it declares the mutual exclusion between csv_text and columns/rows, explains the string-encoding requirement for JSON numbers (to preserve leading zeros in identifiers), and governs request_id reuse. The delimiter parameter's semantics remain undocumented apart from its enum values, so it is not fully compensating.
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?
The description states a specific verb and resource ('Profile a CSV or explicit string table') and immediately scopes it with 'before writing a recipe', which places it in the workflow relative to the preparation/recipe siblings. An agent can tell what it produces (per-column empty/distinct/duplicate counts, formula warnings) without opening the schema.
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?
It gives clear triggering context ('before writing a recipe') and two explicit usage constraints ('Supply CSV OR columns/rows, never both', 'Reuse request_id only for identical input'). It stops short of naming a sibling such as prepare_table or validate_csv as the alternative, so the routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select, rename, derive and convert columns using a caller-owned version-1 recipe. Rules reference original input headers; output follows recipe order and omitted columns are listed. All input rows remain. Any failed conversion returns valid=false, all findings and csv_text=null, never a partially transformed file. No arithmetic, arbitrary code, schema inference or destination writes. One completed report costs one operation, including valid=false. Use reconcile_tables for two-file matching.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | ||
| recipe | Yes | ||
| request_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) by disclosing atomic failure semantics ('valid=false, csv_text=null, never a partially transformed file'), row preservation, output ordering, and operation cost. The only thin spot is the shape of the 'findings' payload on failure, but the failure contract itself is unusually clear.
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?
Front-loaded with the core capability, then layered with failure contract and exclusions in compact declarative sentences with no filler. Slightly dense and clause-heavy in the middle, but every sentence carries distinct information.
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?
No output schema exists, so the description must describe returns, and it does: csv_text plus valid plus findings, with the null-on-failure rule stated. Given the rich nested recipe schema, this is close to sufficient, with only the findings structure left unspecified.
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?
With schema_description_coverage at 0%, the description must carry the parameter burden; it clarifies that rules reference original input headers, that version-1 recipes are caller-owned, and that output follows recipe column order. It says nothing about the table input shape (rows vs csv_text vs delimiter), spreadsheet_safe, or request_id, so the compensation is partial.
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?
Opens with a specific compound verb set (select, rename, derive, convert) applied to columns via a version-1 recipe, which precisely describes the transformation resource. It also names the sibling it is not (reconcile_tables for two-file matching), letting an agent distinguish it without opening the schema.
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?
Explicit scope boundaries are given as exclusions: 'No arithmetic, arbitrary code, schema inference or destination writes,' plus a named alternative for a different task shape. The agent knows both when to reach for this tool and when to route elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Join two bounded tables using exact string or composite keys. Both sides must have non-empty unique keys: duplicates block the entire output, including many-to-many matches. Choose left, inner or full retention explicitly; unmatched records are reported even if excluded. Optional compare fields flag changed values without resolving them. Output includes row lineage; missing-side fields are empty strings. No trimming, fuzzy matching or destination writes. Combined inputs share 1 MB/10,000 records/250,000 cells. One completed report costs one operation; reuse request_id for identical retries. Full findings or an uncharged size error, never silent truncation.
| Name | Required | Description | Default |
|---|---|---|---|
| left | Yes | ||
| right | Yes | ||
| recipe | Yes | ||
| request_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only declaring readOnly/destructive/idempotent flags, the description carries real weight: duplicates block the entire output, unmatched records are reported even when excluded, missing-side fields become empty strings, and size limits (1 MB/10,000 records/250,000 cells) plus one-operation cost and an uncharged size error are disclosed. Silent truncation is explicitly ruled out.
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?
Front-loaded with purpose, then progressively discloses constraints and limits. Dense but every sentence carries operational information; slightly long, yet nothing reads as 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 compute tool with no output schema and no top-level param descriptions, the description covers inputs, output shape (row lineage, empty missing-side fields, value_changed warnings), limits, and idempotency. An agent has enough to invoke it correctly without further documentation.
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?
Top-level schema description coverage is effectively absent, so the description compensates by explaining key semantics (non-empty unique keys, duplicates block output), retention mode meaning, and compare fields as warning-only. It adds genuine meaning beyond the schema, though it does not detail every nested field such as output_delimiter or spreadsheet_safe.
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?
The opening sentence states a specific verb and resource ('Join two bounded tables using exact string or composite keys') and immediately bounds the technique. Combined with sibling names like clean_csv, inspect_table, and prepare_table, an agent can tell this is the reconciliation/join tool, not a cleaning or inspection tool.
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?
It gives clear operational context: choose left/inner/full explicitly, reuse request_id for identical retries, and rules out fuzzy matching or destination writes. It does not name alternative sibling tools or state when-not to use this one, so it stops short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a CSV against your explicit schema; return all issue counts and at most 200 detailed findings. Headers match exactly; required=false permits empty cells, not missing headers. Unique compares raw non-empty strings. Dates use YYYY-MM-DD, decimals use a dot without grouping, booleans use true/false. A valid=false report is a completed paid operation, not a tool failure. No values are changed; use clean_csv for explicit transformations. Validity covers only the supplied rules, not destination-system or business correctness.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes | ||
| csv_text | Yes | CSV text including header. UTF-8, at most 1 MB; no file paths or URLs. | |
| delimiter | No | , | |
| request_id | No | Optional 8–128 character retry key. Reuse only for identical arguments; changed data requires a new key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: result truncation cap ('at most 200 detailed findings'), and critically the billing semantics ('a valid=false report is a completed paid operation, not a tool failure'), which prevents an agent from misreading a failed validation as an error. Also states the no-mutation guarantee and the limited scope of the validity verdict.
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?
Dense but front-loaded, with the core purpose first and constraints ordered by importance. Each clause carries information, though the run-on constraint list could be broken up for readability.
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?
With no output schema, the description still characterizes the return value (issue counts plus capped detailed findings), the error/billing semantics, and the verdict's scope. Nothing an agent needs to call this correctly and interpret the result 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 coverage is 50%, and the description compensates by specifying value-level semantics the schema omits: exact header matching, required=false permitting empty cells but not missing headers, unique comparing raw non-empty strings, and date/decimal/boolean lexical formats. Delimiter and request_id are left to their schema descriptions.
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 ('Check a CSV against your explicit schema') and immediately distinguishes itself from the sibling clean_csv by scope of responsibility. An agent can tell what it does and what it does not do without opening the schema.
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?
Explicitly routes the agent: 'use clean_csv for explicit transformations' and clarifies that this tool changes no values. It also bounds validity to supplied rules rather than destination/business correctness. Missing only explicit negative conditions (e.g. when not to use it at all).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate the fixed example with the current engine. Free and no arguments; demonstrates duplicate, email, amount and date findings. Custom files require validate_csv and paid access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real context beyond them: no arguments required, free of charge, and the specific categories of findings produced (duplicate, email, amount, date). It does not describe output format or pagination, but with no output schema that is a minor gap.
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 does, how to call it, and what to use instead for custom files. Front-loaded with the action and constraints.
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 zero-argument, read-only demo tool with no output schema, the description covers purpose, cost, invocation, expected finding categories, and the sibling alternative. Nothing critical is missing, though return shape for the demo findings is unspecified.
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 the baseline is 4. The description reinforces this with 'no arguments', leaving no ambiguity about how to invoke it.
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 and resource: validates a fixed example with the current engine. It explicitly distinguishes itself from the sibling validate_csv by noting that custom files require that tool. An agent can route correctly without opening any schema.
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?
Explicitly declares 'free and no arguments' and routes the alternative case ('custom files require validate_csv and paid access'). This gives both the when-to-use condition and the when-to-use-something-else condition with the named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Join the bundled fixed tables and show changed and unmatched records. No arguments, key or credit. This cannot process custom data; use reconcile_tables with a paid key for your files.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered structurally. The description still adds real behavioral context: no arguments required, no key or credit needed, and a hard limitation on processing custom data. It stops short of describing the demo's fixed dataset or output shape, but the added constraints are genuinely useful.
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?
Two sentences, both front-loaded with the most decision-relevant facts (what it does, then the alternative routing). No padding or repetition of the title.
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 zero-argument, read-only demo whose annotations already carry the safety profile, nothing needed for correct invocation is missing. The routing to reconcile_tables covers the one decision an agent has to make.
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?
Zero parameters, so the baseline is 4. The description reinforces this with 'No arguments, key or credit,' removing any ambiguity about whether credentials or inputs are expected.
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?
Specific verb and resource: 'Join the bundled fixed tables and show changed and unmatched records' tells the agent exactly what happens. It explicitly distinguishes itself from reconcile_tables by naming that sibling and the condition (custom data) that selects it.
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?
States when to use it (free, no key, bundled data) and when not to ('This cannot process custom data; use reconcile_tables with a paid key for your files'). The alternative and the switch condition are both explicit.
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.
get_table_exampleinspect_tableprepare_tablereconcile_tablesview_table_democlean_csvget_csv_exampleget_csv_usagevalidate_csvview_csv_demoClean, dedupe, join and reconcile CSV/Excel files. Runs on Apify, pay per use.
Convert and clean tables: CSV, JSON, dedupe, stats. Free.
Normalize messy CSV into your schema; ambiguous values return as exceptions. $0.02 USDC via x402.
Validate JSON, YAML, XML and CSV with exact line/column errors and silent-corruption warnings.
Add one secure layer between your agents and this server.