TelescopeCompareHQ: the site's own MCP server — dataset, enquiry (enquiry = a human handoff, not...
Scored across 10 tools
Dataset tools are mostly distinct by query type: schema, provenance, exact row, substring search, multi-value compare, stats, and top. However, dataset_row, dataset_search, and dataset_compare form a spectrum of filtering and could be confused without reading the descriptions carefully. Enquiry tools are clearly separated by purpose.
All names use snake_case and group naturally into dataset_* and enquiry_* families. The only notable deviation is submit_enquiry, which uses a verb-first pattern while the related tools are enquiry_describe and enquiry_fields. This is minor and still readable.
With 10 tools, the set is well-scoped for its dual purpose: querying a TelescopeCompareHQ dataset and submitting an enquiry. Each tool earns its place, with no redundant or trivial operations.
The dataset surface covers schema discovery, provenance, row retrieval, search, comparison, statistics, and top/bottom ranking, which supports common analytical questions. The enquiry flow includes description, fields, and a two-step submission, but lacks status-checking or cancellation, though these may not be needed for a one-way enquiry. Minor gaps remain around arbitrary multi-column filtering.
The columns, which of them are numeric, the row count and the provenance banner of the TelescopeCompareHQ 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 shape and the recommended call order. However it says nothing about safety profile, auth requirements, or whether the result is cached/static — though for a zero-argument read-only introspection tool the risk surface is minimal.
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, zero redundancy, with the payload contents front-loaded and the calling instruction second. 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?
With no output schema, the description must describe returns, and it does so well by enumerating the four things returned. Minor gap: it does not explain what the 'provenance banner' contains or its format, which an agent might want before deciding whether dataset_provenance is also needed.
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. There is nothing to disambiguate, and the schema is empty as 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?
States a specific resource (the dataset's schema) and enumerates exactly what is returned: columns, which are numeric, row count, and provenance banner. This distinguishes it from siblings like dataset_row or dataset_stats, which return data values rather than schema metadata.
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 that routes the agent correctly on entry. It does not name an alternative or exclusion, so it falls short of the 5-level when/when-not benchmark.
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 TelescopeCompareHQ 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?
No annotations are provided, so the description carries the full burden. It does disclose one non-obvious behavioral trait — results come back 'in the order given' of the values — but says nothing about read-only safety, what happens when a value matches no row (omit vs. error), or the 10-value ceiling. The useful ordering disclosure keeps this above a floor score despite the gaps.
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 that spends no words on restating the title. The phrasing 'whose column is any of the given values' is slightly convoluted, but there is no filler and the usage hint is correctly placed at the end.
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 are no annotations and no output schema, so the description is the sole source of behavioral detail for a 2-parameter tool. It adequately conveys the filtering model and output ordering, but leaves the returned row shape (all columns?) and the value-count limit unstated — gaps that matter more given the absent annotation coverage.
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. It explains the match semantics ('whose column is any of the given values', i.e. an any-of filter keyed on `column`) and that value order matters, which is meaningful beyond the bare string/array types. It does not mention the 2-10 item bounds or that partial matches are excluded.
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 retrieval action on a named resource (rows of the TelescopeCompareHQ dataset filtered by a column's values) and adds an intent gloss ('for X vs Y questions'). The verb 'Return/Get' is only implied, but an agent can distinguish this filtered, multi-value lookup from siblings like dataset_row and dataset_top.
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 trailing '— for "X vs Y" questions' gives an implied usage condition that points at comparison queries, which is genuinely useful. However, it never names an alternative tool or states when NOT to use this (e.g., single-value lookups belong to dataset_row), so the routing guidance is inferred rather than explicit.
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 TelescopeCompareHQ 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, the description must carry the behavioral burden, and it does the important part: it declares this is a read of metadata fields. There is no mention of side effects, format, or permissions, but a parameterless metadata lookup has almost no behavioral surface to disclose.
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, front-loaded with what the tool returns and closed with why to call it. Nothing is padded or 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?
There is no output schema, so the description correctly takes on the job of describing the returned payload, listing all four fields. It stops short of stating the return format (structured vs prose), a minor gap for such a simple tool.
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 schema defines zero parameters, so baseline is 4. The description usefully enumerates the fields returned (source, date, licence, citation), which is the only meaningful semantic content available for a no-input tool.
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 resource it returns: source, computation date, licence and citation for the TelescopeCompareHQ dataset. That content list makes it distinguishable from the other dataset_* siblings, though it never names an alternative to contrast against.
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 a clear, specific condition for use rather than generic filler. It offers no exclusions or named alternatives, but for a zero-param metadata tool the trigger condition is sufficient.
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 TelescopeCompareHQ 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 exist, so the description carries the full burden. It usefully discloses two behavioral traits beyond the schema: matching is exact and case-insensitive. However, it says nothing about how many rows can come back, result limits, ordering, or whether the value must match a valid column name, leaving meaningful behavioral gaps.
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 no filler; the key constraint (exact, case-insensitive) is front-loaded where an agent will see it.
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-required-param lookup with no annotations and no output schema, the description covers the matching semantics but not the return shape or result-cardinality limits. It is adequate to attempt a call but not complete enough to predict the outcome.
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. It does explain the relationship between the two params ('a column equals a value') and that comparison is case-insensitive, which adds real meaning. It does not say whether 'column' must be an existing dataset column or give any format examples, so the compensation is only 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?
States a specific verb and resource ('the rows of the TelescopeCompareHQ dataset') and adds the selection rule (column equals value exactly, case-insensitive). The word 'exactly' implicitly separates it from a fuzzy sibling like dataset_search, but no sibling is named, so an agent must infer the boundary.
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 exactness/case-insensitivity phrasing, which hints this is the tool for precise key lookups rather than search. There is no explicit statement of when to prefer dataset_search or dataset_top instead, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rows of the TelescopeCompareHQ 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 behavioral burden, and it does disclose useful traits: matching is case-insensitive and applies to any cell, and results are capped at 50 rows. However, it says nothing about ordering, what happens when more than 50 rows match (truncation?), or the shape of the returned rows, and never states the read-only nature explicitly.
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 with no filler, front-loading the resource and the matching rule ahead of the result cap. Every clause carries information, though the phrasing is terse enough that ordering and truncation behavior are squeezed out.
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-only search with no output schema and no annotations, the description covers matching semantics and the result cap, which is the core of what an agent needs. It leaves gaps on result ordering, truncation signaling when more than 50 rows match, and the structure of returned rows, so it is adequate but not 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?
Schema coverage is 50%: the query parameter is self-documented, but limit is not. The description compensates by explaining both — query means matching cell text case-insensitively, and the cap of 50 corresponds to the limit parameter. It adds meaning beyond the raw types, though it omits that limit has a minimum of 1.
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 verb (search) plus the exact resource (rows of the TelescopeCompareHQ dataset) and the matching semantics (cells containing the query, case-insensitive). This is clearly a text-lookup operation, distinguishable from siblings like dataset_row (single row fetch), dataset_stats, and dataset_compare. It stops short of naming any sibling explicitly, so it lands at 4 rather than 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?
There is no when-to-use guidance and no distinction drawn against alternatives such as dataset_row, dataset_top, or dataset_columns, even though the sibling list shows several overlapping 'get rows' tools. Usage is only implicit: an agent must infer that this is the tool for free-text matching rather than keyed retrieval or aggregation.
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 TelescopeCompareHQ 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-obvious behavior: grouping commas and currency symbols are parsed, and non-numeric rows are excluded and counted. It does not state permissions/read-only nature or what error surfaces if the column is entirely non-numeric, but the parsing and exclusion semantics are the key traits an agent needs.
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, front-loaded with the returned statistics and followed by the parsing/edge-case clause. No filler or repetition of the name or 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?
With no output schema, the description usefully enumerates the returned metrics (count, min, max, mean, median, sum), and it covers the main data edge case. Minor gaps remain: no mention of result ordering, error behavior for a fully non-numeric column, or how the excluded-row count is surfaced.
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 0% and there is one required parameter, so the description must compensate. It does: the 'column' argument must be a numeric column of the TelescopeCompareHQ dataset, which tells the agent what values are valid beyond the bare string type in the schema.
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 set (count, min, max, mean, median, sum) and resource (a numeric column of the TelescopeCompareHQ dataset), so the operation is unambiguous. It does not explicitly contrast itself with siblings like dataset_top or dataset_columns, but its purpose is clear enough to select 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?
Usage is implied rather than stated: the tool applies to a numeric column of a specific dataset. There is no explicit guidance on when to prefer this over dataset_top, dataset_columns, or dataset_search, and no stated preconditions or error cases for a non-numeric column.
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 TelescopeCompareHQ 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 behavioral burden, and it falls short. It says nothing about what is returned (rows with which columns), how ties or non-numeric values are handled, or whether the result is capped at the schema's limit of 50.
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 wasted words. The em-dash gloss is slightly discursive but adds intent framing rather than 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 annotations, no output schema, and a partially documented 3-parameter schema, the description should say more about the shape of the result and the interaction of column/limit/ascending. As written it leaves an agent guessing about the return payload.
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 33% (only 'ascending' is documented), so the description must compensate. It does add one useful constraint — that 'column' must be numeric — and 'highest (or lowest)' reinforces the ascending flag, but it says nothing about 'limit' behavior or 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?
States a specific operation (return the highest/lowest rows of the TelescopeCompareHQ dataset, ranked by a numeric column) with a natural-language framing of the intent. It is clearly distinct from dataset_search or dataset_stats by name alone, but it never explicitly contrasts itself with those siblings, which is what a 5 requires.
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 quoted 'which is the most/least X' framing implies the usage context, so an agent can infer intent. However, it gives no explicit when-to-use guidance against dataset_stats or dataset_search, no prerequisites, and no exclusions.
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 TelescopeCompareHQ: 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 full burden, and it does disclose meaningful behavior of the surrounding flow: nothing is bought, ordered or paid, no quote is guaranteed, it is free. However, it says little about the tool's own behavior (is it a pure read? does it touch any state?), so transparency is partial.
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 passage is short and front-loaded with "Read first," but it spends most of its words describing a sibling tool rather than itself, which dilutes focus. It is not padded, but the allocation of sentences is off-centre.
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 convey return content, and it does: the recipients of details, the consent wording, and the confirmation step. This is enough for an agent to know what calling it yields, though it never states the format of that information.
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 per the rubric the baseline is 4. There is nothing to disambiguate and no schema gap to compensate for.
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 explains the subject matter (what an enquiry is, what submit_enquiry does) and lists the returned content, but it never plainly states that enquiry_describe is a read-only informational tool about the enquiry flow. The reader must infer the tool's own function from the framing rather than read a direct verb+resource statement.
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" implies this should be consulted before using the sibling submit_enquiry, which is useful sequencing guidance, but no alternative tool is named and no explicit when-not condition is given. Usage is implied rather than stated.
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 TelescopeCompareHQ 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, the description bears the full disclosure burden. It usefully reveals the shape of the returned field metadata and its role as input to submit_enquiry, but never states that this is a side-effect-free read, whether authentication is required, or what happens on error/empty results.
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, fully front-loaded: the returned content comes first, the actionable hand-off second. No filler, no restatement of the tool name.
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 compensates by listing the fields returned and noting the conditional allowed-options list. It is complete enough to call and consume, though it omits error/empty-state 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?
Zero parameters, so the baseline is 4. The description nonetheless adds meaning about the returned 'key' by explaining that it is the identifier submit_enquiry expects for answers, which is useful semantics not implied by the empty schema.
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 precisely enumerates what is returned (key, label, type, required flag, help text, allowed options) for the TelescopeCompareHQ enquiry, which makes the resource and payload unambiguous. The verb is only implicit ('Every field of the...'), and it does not explicitly contrast itself with the closely-named sibling enquiry_describe.
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 states a concrete downstream workflow: answers gathered against these fields should be passed to submit_enquiry keyed by field key, which tells the agent how this tool fits into the enquiry flow. It does not, however, say when to prefer this over enquiry_describe or what to do if the enquiry definition is absent.
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 TelescopeCompareHQ — 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: "By submitting you agree TelescopeCompareHQ emails you a recommendation and shares nothing else with 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: By submitting you agree TelescopeCompareHQ emails you a recommendation and shares nothing else with 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 does so: it discloses that nothing is purchased, that step 1 is validation-only and returns a summary/consent line/token, that submission triggers an email with a required click before any provider sees the enquiry, and reproduces the exact consent text. These are non-obvious behaviors an agent could not infer from the 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?
The description is a single dense paragraph but is clearly front-loaded (what it is / what it is not) before the Step 1 / Step 2 breakdown. The quoted consent line is repeated content that adds length, but it is load-bearing since it must be shown verbatim to the person.
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 mutation tool with no annotations and no output schema, the description still explains what each call returns and the required downstream user actions (show summary, obtain agreement, click email link). Nothing an agent needs to invoke it correctly 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 baseline is 3; the description goes beyond it by tying each parameter to the flow ('keyed by field key from enquiry_fields', consent=true meaning, and the confirmation token coming from step 1 after approval). It adds sequencing semantics rather than just restating the schema.
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 TelescopeCompareHQ') and immediately delimits scope with 'NOT a purchase, NOT a guaranteed quote'. It also references the sibling enquiry_fields as the source of the answer keys, so the agent can distinguish it from the read-only dataset_* and enquiry_describe/enquiry_fields tools.
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 spelled out as an explicit two-step protocol: Step 1 call with answers+consent=true, Step 2 call again with the confirmation token 'only if the person agrees'. It also names the upstream dependency (field keys from enquiry_fields), leaving nothing to inference about when each call is appropriate.
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_enquiryRMMCompare: the site's own MCP server — dataset, enquiry (enquiry = a human handoff, not a...
EntitySearch HQ: the site's own MCP server — dataset, enquiry (enquiry = a human handoff, not a...
Rechner HQ: the site's own MCP server — dataset, enquiry (enquiry = a human handoff, not a...
FlightDelayHQ: the site's own MCP server — dataset, enquiry (enquiry = a human handoff, not a...
