Medicare Plan Comparison: the site's own MCP server — dataset, enquiry (enquiry = a human...
Scored across 10 tools
Most tools target clearly distinct operations: schema, provenance, stats, top, compare, search, row. However dataset_row (exact equals), dataset_search (substring contains), and dataset_compare (X vs Y) have overlapping retrieval purposes that could cause misselection. The enquiry group (describe/fields/submit) is clearly separated.
Seven dataset_* tools share a consistent prefix and noun-oriented naming (columns, provenance, row, search, stats, top, compare). The enquiry group is mostly enquiry_* (describe, fields), but submit_enquiry flips to verb_noun, a minor deviation. Overall predictable and readable.
10 tools is well within the ideal 3-15 range and each earns its place. The 7 dataset tools are slightly granular (row/search/compare/top/stats could arguably merge), but the scoping is reasonable for a dataset-plus-enquiry server.
The read-only dataset surface is thoroughly covered: schema, free-text search, exact match, comparison, ranking, aggregation, and provenance. The enquiry lifecycle has describe/fields/submit including a two-step confirmation flow. Minor gap: no multi-condition filtering, but core workflows are complete.
The columns, which of them are numeric, the row count and the provenance banner of the Medicare Plan Comparison dataset. Call this first to learn the schema.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, and it does disclose the return payload. However, it never states that the tool is read-only, has no side effects, or is deterministic — reasonable inferences for a zero-argument tool, but unstated.
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 with zero filler, and the call-to-action ('Call this first') is front-adjacent after the payload listing. Nothing redundant.
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 enumerates the returned fields, which compensates. It is nearly complete for a simple read tool, missing only an explicit statement of side-effect-free behavior.
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 no parameters, so there is nothing to document; the baseline for a zero-parameter tool is 4.
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 resource and enumerates what it returns: columns, numeric flags, row count, provenance banner. The overlap with siblings dataset_provenance and dataset_stats is not addressed, so an agent can't tell from the description alone whether those tools return the same banner or count.
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 to learn the schema' gives explicit ordering guidance and a clear trigger, which is genuinely useful for an agent planning a multi-step dataset investigation. It stops short of naming alternatives or when-not-to-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The rows of the Medicare Plan Comparison dataset whose column is any of the given values, in the order given — for "X vs Y" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| column | Yes | ||
| values | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full behavioral burden, and it only discloses one trait: output order follows the order of the supplied values. It is silent on what happens when a value matches nothing, whether the dataset is fixed or selectable, how large the result can be, or that the operation is a non-mutating read.
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?
One sentence, front-loaded with the dataset and the selection rule, with no filler. The phrasing 'whose column is any of the given values' is grammatically tangled (a column does not equal a value), which slightly hurts parseability, but there is no wasted text.
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?
Two required parameters, zero annotation coverage, zero schema descriptions, and no output schema — so the description is the only source of guidance, and one sentence is not enough. An agent still cannot tell what the returned rows look like, how missing matches are handled, or what 'side by side' comparison actually produces.
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 0%, so the description must compensate, and it partially does: it explains that `values` are matched against the named `column` and that result ordering tracks the given order. It does not explain the maxItems=10 / minItems=2 constraints or that `column` is a dataset column identifier rather than a free-form value.
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 the resource (rows of the Medicare Plan Comparison dataset) and the selection rule (column matches any given value, order preserved), which is enough to know roughly what comes back. However, the title promises 'Compare rows side by side' while the text describes a filtered row retrieval — the actual comparison behavior is never explained. No sibling is named or contrasted, so the agent must infer why this differs from dataset_search or dataset_row.
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 closing clause 'for "X vs Y" questions' gives an explicit invocation scenario, which is more than most definitions offer. It stops short of naming alternatives (e.g., when to use dataset_search instead) or stating exclusions, so it stays at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The source, the date it was computed, the licence and the citation for the Medicare Plan Comparison dataset. Read this to attribute a figure correctly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden, and it does disclose the exact contents an agent will receive: source, compute date, licence and citation. It stops short of stating read-only/safety characteristics or the citation format, but for a static metadata lookup the disclosure is solid.
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 the payload listed first and the actionable instruction last. Every clause earns its place and there is 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?
No output schema exists, but the description enumerates the returned fields, which largely compensates. Minor gaps remain: the exact format of the licence/citation strings and confirmation that it covers only the Medicare Plan Comparison dataset are unstated.
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 of 4 applies. The description correctly implies no input is needed, though it adds no further parameter-related detail because there is none to add.
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 names the exact content returned (source, computation date, licence, citation) for a named dataset, which is clearly distinct from the data-oriented siblings like dataset_columns, dataset_stats and dataset_search. It does not name a sibling directly, but the resource and payload are unambiguous.
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?
"Read this to attribute a figure correctly" gives one concrete usage cue, so the intent is implied rather than spelled out. There is no explicit when-not guidance and no alternatives (e.g. dataset_row) are mentioned for retrieving the underlying figure itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The rows of the Medicare Plan Comparison dataset where a column equals a value exactly (case-insensitive).
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| column | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It does disclose a real behavioral trait beyond structured fields — case-insensitive exact equality and that multiple rows may match — but says nothing about result limits, ordering, pagination, or what happens when nothing matches.
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 compact sentence with the dataset scope and matching rule front-loaded and no filler. It is a sentence fragment without an explicit verb, which slightly reduces polish but costs nothing in clarity.
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 no annotations, so the description should describe the return shape and no-match behavior; it instead leaves the agent to guess whether it returns a list of row objects and how many. For a simple two-parameter lookup this is a moderate but real gap.
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 0% with two required string parameters, so the description must compensate. It does bind the parameters semantically ('where a column equals a value'), clarifying their relationship, but gives no guidance on column naming conventions, valid column identifiers, or value format.
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 names the resource (rows of the Medicare Plan Comparison dataset) and the precise retrieval semantics (a column equals a value exactly, case-insensitive), which is a specific verb+resource statement. It does not explicitly contrast itself with the sibling dataset_search, so an agent must infer the exact-match vs. text-search distinction.
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 emphasis on 'equals a value exactly' suggests this is the tool for precise key lookups rather than fuzzy queries, but no when-to-use condition or alternative (dataset_search, dataset_top) is named. An agent must infer when exact lookup beats searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rows of the Medicare Plan Comparison dataset whose cells contain the query (case-insensitive), up to 50.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | text to look for in any cell |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose genuine behavioral traits not in the schema: matching is case-insensitive and applies to any cell, and results are capped at 50. However it says nothing about result ordering or what happens when more than 50 rows match (truncation vs. paging).
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 resource and matching semantics come first and the cap closes it. It is arguably too terse rather than padded, so it does not waste space but also omits useful context.
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 read tool with no output schema, the description covers matching semantics and the result cap, which is the minimum viable. It leaves gaps around ordering, truncation behavior, and routing versus the other dataset_* tools.
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%: the query param is documented ('text to look for in any cell') while limit is not. The description partially compensates by stating 'up to 50', which explains the effective cap on the otherwise-undocumented limit parameter, but adds no syntax or default detail.
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 names a concrete verb (search/return) and resource (Rows of the Medicare Plan Comparison dataset) and states the matching rule (cells containing the query). It is specific enough to distinguish from dataset_row or dataset_top, though it never explicitly names those alternatives.
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 and no named alternative among the nine sibling tools (dataset_row, dataset_top, dataset_stats, dataset_columns). The text-search semantics imply a use case, but the agent gets no help deciding between this and its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
count, min, max, mean, median and sum of a numeric column of the Medicare Plan Comparison dataset (grouping commas and currency are handled; non-numeric rows are excluded and counted).
| Name | Required | Description | Default |
|---|---|---|---|
| column | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose non-trivial data-handling behavior: grouping commas and currency are parsed, and non-numeric rows are excluded and counted. It does not state permissions, read-only nature, or what the count field represents relative to the excluded rows, but for a read-only aggregate query the disclosed edge-case handling is solid.
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 dense sentence that front-loads the returned statistics, then packs the data-cleaning caveats into a compact parenthetical. Nearly every clause earns its place; the parenthetical is information-dense rather than padded.
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 correctly enumerates the return values (count, min, max, mean, median, sum), which is the main thing an agent needs. The remaining gap is a lack of guidance on dataset selection or failure behavior when the column is entirely non-numeric.
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 0% and the single 'column' parameter has no description in the schema, but the prose constrains it usefully by requiring a numeric column and by noting non-numeric input rows are excluded rather than rejected. That adds meaning beyond the bare string/minLength schema, but format or naming conventions for the column are still unstated.
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?
Names a specific operation (summary statistics) on a specific resource (a numeric column of the Medicare Plan Comparison dataset) and enumerates the outputs. An agent can tell it apart from dataset_row, dataset_top, and dataset_search by the aggregate-statistics framing, though no sibling is named explicitly.
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 conveys implied usage (get stats for a numeric column) but gives no when-to-use guidance, no exclusions, and no routing to alternatives such as dataset_top or dataset_row. It also does not say what to do if the requested column is non-numeric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The highest (or lowest) rows of the Medicare Plan Comparison dataset by a numeric column — "which is the most/least X".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| column | Yes | ||
| ascending | No | true for the lowest first; default highest first |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not state that the operation is read-only, does not mention the 50-row cap on results, does not explain tie-breaking or default ordering beyond what the schema says, and gives no sense of the return shape.
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 tight sentence with the core operation front-loaded and no filler. The em-dash clause is slightly informal but earns its place by capturing the user intent.
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 three parameters, no output schema, and no annotations, the description should do more work. It omits the result-size cap, the default sort direction, and any indication of what a returned row looks like, leaving meaningful gaps for an agent to guess at.
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 only 33% (only 'ascending' is documented), so the description must compensate. It implies column ranking and direction via 'highest (or lowest)', but never mentions the 'limit' parameter or its 1-50 bounds, leaving a third of the parameters undocumented in both places.
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 names a specific operation (returning the highest/lowest rows) on a specific resource (the Medicare Plan Comparison dataset) and frames the intent with 'which is the most/least X'. It is clearly distinguishable from dataset_row or dataset_search, though it doesn't explicitly name a sibling to contrast with.
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 'which is the most/least X' framing implies the question shape this tool answers, giving implied usage context. However, there is no explicit guidance on when to prefer this over dataset_stats, dataset_search, or dataset_row, and no exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read first. States plainly what submit_enquiry does on Medicare Plan Comparison: it starts an enquiry with human providers who quote directly. Nothing is bought, ordered or paid; no quote is guaranteed; it is free. Also returns who receives the details, the consent wording, and how the person confirms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses important behavioral context: nothing is bought, no quote is guaranteed, and it returns recipient/consent/confirmation details. It implies a read-only informational role but does not explicitly state this tool has no side effects, keeping 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?
The description is short, front-loads the directive "Read first," and each sentence adds relevant information without waste. It is appropriately sized for a simple informational tool.
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, no-output-schema describe tool, the description sufficiently explains what the tool returns and the context around submit_enquiry. It could be slightly more explicit that the tool itself does not submit anything, so a 5 is not warranted.
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 has zero input parameters, so there are no parameter semantics to document. The baseline for 0 params is 4, and the description does not need to add parameter detail.
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 clearly states that the tool explains what submit_enquiry does and returns consent-related details. It names the related tool (submit_enquiry) but does not explicitly differentiate itself from sibling enquiry_fields, so it falls short of a 5.
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?
"Read first" gives clear context that this tool should be consulted before submit_enquiry. However, it does not mention alternatives such as enquiry_fields or any exclusions, so it lacks the full guidance of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every field of the Medicare Plan Comparison enquiry: key, label, type, whether required, help text and the allowed options where there are any. Pass answers to submit_enquiry keyed by field key.
| 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. It does disclose the return shape (field metadata and allowed options), which is useful since there is no output schema, but it says nothing about read-only safety, auth requirements, caching, or whether the field set can change between calls.
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, no filler, and the payload contents are front-loaded before the submit_enquiry guidance. Slightly list-heavy but every clause earns its place.
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 no annotations, yet the description enumerates the returned fields and their purpose, which adequately compensates for the missing structured metadata. Only minor gaps remain around auth and freshness.
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 disambiguate; baseline 4 applies. The schema is empty and the description correctly implies none are needed.
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 names the specific resource (every field of the Medicare Plan Comparison enquiry) and enumerates the exact data returned: key, label, type, required, help text, options. That is far more specific than the vague title and clearly differentiates it from sibling retrieval tools like dataset_columns or enquiry_describe, though it never explicitly contrasts with 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?
It gives a downstream usage hint: 'Pass answers to submit_enquiry keyed by field key,' which tells the agent why to call it and how the output feeds a sibling tool. However, it never states when to call this versus the adjacent enquiry_describe tool, nor any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submits an enquiry to Medicare Plan Comparison — NOT a purchase, NOT a guaranteed quote. Step 1: call with the answers (keyed by field key from enquiry_fields) and consent=true; it validates and returns a summary, the consent line and a confirmation token — show the person the summary and the consent line. Step 2: only if the person agrees, call again with the same answers, consent=true and the confirmation token; the enquiry is then submitted, and the person receives an email with a link they must click before any provider sees it. Consent means the person has read and agreed to: "This site has no form. It does not take your details and passes nothing to anyone."
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | the person's answers, keyed by field key | |
| consent | Yes | true only when the person has agreed to: This site has no form. It does not take your details and passes nothing to anyone. | |
| confirmation | No | the confirmation token from step 1, after the person has approved the summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: it discloses that this is not a purchase, that step 1 only validates and returns a summary/consent line/token, that submission requires a second call, and that the person must click an emailed link before any provider sees the enquiry. These are material behavioral traits an agent could not otherwise know.
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?
Long but front-loaded, with the crucial "not a purchase" caveat first and the steps sequenced logically. The closing consent quote mildly duplicates the consent field's schema description, but it is central to correct invocation.
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 explain returns — and it does, naming the summary, consent line and confirmation token. Combined with the two-step gate and email-click requirement, an agent has everything needed to call it correctly.
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 already 100%, so the baseline is 3, but the description adds real meaning: answers are keyed by field key from enquiry_fields, and confirmation is the step-1 token used only after approval. It explains the inter-parameter flow rather than restating types.
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 ("Submits an enquiry to Medicare Plan Comparison") and immediately disambiguates scope with "NOT a purchase, NOT a guaranteed quote." An agent can distinguish this from the sibling enquiry_fields/enquiry_describe tools, which it references for input keys.
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 lays out an explicit two-step procedure: Step 1 with answers + consent=true to validate, Step 2 only if the person agrees, re-calling with the confirmation token. The condition selecting each step and the dependency on enquiry_fields for answer keys are spelled out rather than inferred.
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.
dataset_columnsdataset_comparedataset_provenancedataset_rowdataset_searchdataset_statsdataset_topenquiry_describeenquiry_fieldssubmit_enquiryStructured Settlement Compare: the site's own MCP server — dataset, enquiry (enquiry = a human...
Equipment Rental Compare: the site's own MCP server — dataset, enquiry (enquiry = a human...
Insurance by Profession: the site's own MCP server — dataset, enquiry (enquiry = a human...
Answering Service Quotes: the site's own MCP server — dataset, enquiry (enquiry = a human...