Convert CSV, XLSX and PDF files to JSON, read web pages into structure, and source datasets.
Scored across 4 tools
The list/describe pair on 'propositions' follows a well-known pattern, and extract_web_page and submit_request are clearly distinct from them. The only friction is the word 'proposition' itself, which is vague enough that an agent may not immediately know whether describe_proposition is a detail view or an operation list.
All four tools use consistent snake_case verb_noun form (list_, describe_, extract_, submit_), with predictable list/describe symmetry on the same resource. No convention mixing or vague one-word names.
Four tools is on the lean side but reasonable for a narrow server: one extraction tool plus a small service-catalog/request trio. Nothing feels redundant or padded, though the conversion capability named in the server title is only reachable indirectly.
The headline capability — CSV/XLSX/PDF to JSON conversion — has no dedicated tool and is only reachable through the opaque submit_request, and there is no tool to retrieve request results or check status by reference number. Discovery, description and submission are covered, but the lifecycle dead-ends after submission.
Everything about one service: what happens to a request, what you get, scope and limits, the request fields and any operations.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only that the payload is comprehensive in scope, without saying what happens for an unknown slug, whether an error is raised, or how large the response is. It neither contradicts nor meaningfully extends the annotations.
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?
It is a single front-loaded sentence with a colon-delimited list, which is structurally sound and short. But several list items are vague ('what you get', 'any operations'), so brevity comes at the cost of specificity rather than being purely efficient.
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 is the only source of return-value information, and it does gesture at the main content categories. Against the simplicity of a one-parameter read tool with rich annotations, that is roughly adequate, but the undefined slug and absent error/edge-case behavior leave gaps.
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 single parameter, slug, has 0% schema description coverage, so the description carries the full burden and does not meet it — 'slug' is never explained as the service identifier, its expected format, or where to obtain it. The items listed ('request fields', 'operations') describe response content, not the input, so they do not compensate for the schema gap.
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 conveys that this is a detail-lookup for a single service and enumerates the kinds of content returned (request flow, response, scope/limits, fields, operations). However, it never states an explicit verb and shifts terminology from the tool name's 'proposition' to 'service', which leaves the agent to infer that these are the same entity. The singular framing loosely implies a contrast with list_propositions, but no explicit differentiation is made.
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?
There is no when-to-use guidance at all: nothing says to call this instead of list_propositions when the agent already has a slug, and nothing mentions the sibling tools. The description also never hints at what precondition must hold (a valid slug) before calling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one public web page into title, headings, text, links and JSON-LD. robots.txt is honoured.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds two pieces of genuine behavioral context beyond that: only public pages are eligible, and robots.txt restrictions are respected (so a request can legitimately be refused). It still says nothing about page-size limits, truncation, or failure modes on non-HTML content.
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 with no filler. The output contract is front-loaded and the robots.txt caveat follows immediately, so nothing is buried or wasted.
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 correctly compensates by listing what is returned. For a single-parameter read tool whose safety profile is already in the annotations, this is close to complete; only edge-case behavior (truncation, non-HTML pages, redirect handling) is absent.
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?
There is one parameter with 0% schema description coverage, so the description must carry the semantics. "One public web page" usefully conveys a single, publicly reachable URL, but it does not state accepted schemes, whether redirects are followed, or that the string is length-capped at 2000 characters.
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 gives a specific verb ("Read") plus a specific resource ("one public web page") and enumerates the extracted artifacts (title, headings, text, links, JSON-LD). That is far more informative than a restatement of the name. No sibling differentiation is offered, but the sibling tools (describe_proposition, list_propositions, submit_request) are unrelated, so confusion risk is low.
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 only implied: the tool takes a page and returns structure, and "public" plus "robots.txt is honoured" hint at eligibility limits. There is no explicit when-to-use/when-not guidance, no statement about non-HTML, paywalled, JS-rendered, or authenticated pages, and no named alternative to reach for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Decant's services with a one-line summary: lookups that run instantly, and requirements you can send.
| 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, so safety is covered. The description adds that each entry carries a one-line summary and that listings fall into two kinds, which is useful context, but it says nothing about ordering, count, or response shape for a tool with no 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?
A single front-loaded sentence with no filler. The trailing clause 'requirements you can send' is vague enough to cost a point but the structure itself is efficient.
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-parameter, non-destructive listing tool this is close to sufficient, but with no output schema the agent must rely on the description to know what comes back beyond 'one-line summary'. The unexplained terminology ('services' vs 'requirements' vs the name's 'propositions') leaves the agent guessing at the catalogue's contents.
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 4 applies. The description does not misrepresent any input.
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 verb and resource are stated ('List Decant's services with a one-line summary'), but the tool name uses jargon ('propositions') that the description renames as 'services', creating a mismatch an agent must resolve. The two categories given ('lookups that run instantly' and 'requirements you can send') are evocative but not precise, and do not cleanly separate this tool from describe_proposition.
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?
No explicit when-to-use guidance and no sibling is named as an alternative. The phrase 'requirements you can send' loosely gestures at submit_request without saying so, which risks the agent invoking the wrong tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a requirement to one of Decant's services. It is kept with a reference number.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | The requirement in words | |
| slug | Yes | Service slug, or anything-else | |
| action | No | ||
| budget | No | ||
| timing | No | ||
| contact | No | Optional; stored apart and deleted after 180 days | |
| quantity | No | ||
| geography | No | ||
| specifications | No | Fields from the service's request schema | |
| requested_fields | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the agent knows this writes and that repeats create new records. The description usefully adds that the request is persisted ('kept') and that a reference number identifies it, partially compensating for the missing output schema. It says nothing about permissions, turnaround, or what happens to duplicate submissions.
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 with no filler and the action front-loaded. It is efficient, though the brevity is partly under-specification rather than disciplined editing.
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, nested-object submission tool with no output schema and low schema coverage, the description is thin: it never explains how to discover a valid slug, how 'specifications' should be populated, or how the returned reference number is used later. The one privacy-relevant fact in the definition (contact details stored separately and deleted after 180 days) sits only in the schema.
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 only 40% across 10 parameters including nested objects, and the description adds no parameter meaning at all. The most consequential fields are unexplained: 'specifications' ('Fields from the service's request schema') and 'requested_fields' beg for guidance on where those field names come from, and the cryptic slug note 'or anything-else' is not clarified.
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 ('Send') and resource ('a requirement') and names the target ('one of Decant's services'), so the create-a-request purpose is legible. It does not distinguish itself from the siblings (describe_proposition, list_propositions, extract_web_page) or clarify whether it submits to an existing service or an arbitrary 'anything-else' destination.
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?
No when-to-use guidance: nothing says whether this is the entry point for a new requirement, whether you must first call describe_proposition to learn the service's request schema, or when to use the free-text 'need' versus structured fields. Alternatives and prerequisites are entirely left to inference.
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.
describe_propositionextract_web_pagelist_propositionssubmit_requestExtract text, tables and metadata from every PDF linked in a dataset, CSV or Google Sheet.
Read, filter, group and write XLSX, CSV, TSV and JSON data, and convert between the formats.
Extract every table from PDFs and scans to Excel, CSV and JSON.
PDF URLs to per-page text, tables as rows, Markdown, metadata and OCR for scanned pages.
Add one secure layer between your agents and this server.
