7Maps

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is low. The description adds genuinely useful behavior beyond them: the call is free ("No charge", reinforced by the title), the worked example changes daily, and naming a server yields a savings quote before payment. Missing rate/return-format detail keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The usage trigger is front-loaded in the first clause, and the remaining text enumerates concrete deliverables (coverage, per-tool answers, cost, savings, example, quote). It is dense but every clause carries distinct information; the nested commas make it slightly heavy for a single long sentence pair.

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 carry the return contract, and it does: it lists exactly what a caller gets back (map coverage, tool-by-tool answers, costs, savings comparison, live example, optional quote). Only the freshness/pagination handling of the whole response is left 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?

With 1 parameter at 100% schema coverage, the schema already documents `server` fully, including its optionality and purpose. The description largely restates it (quote of tokens/time saved on a named server before paying) without adding format, constraints, or fallback behavior, so baseline 3 is appropriate.

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 role: it explains what 7Maps is, what the map covers, what each tool answers, call costs, and token/time savings, plus a worked example and optional per-server quote. That is far more than a restatement of the name. It never names a sibling tool to differentiate itself (e.g. tool_card, which could also describe tools), so it stops 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?

"Use this when deciding whether to use 7Maps, or when asked what it is" gives an explicit adoption condition rather than implying usage. It does not state when NOT to call it or name alternative informational tools, so it lacks the exclusions/explicit alternatives that would earn a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world. The description adds genuinely new context: paid per call, 'reads the map only', the likely empty-result outcome, and that submitting last_trip reports earns a free call after 5 accepted reports. It does not explain pagination or output shape, but no output schema exists so that gap is modest.

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 dense but front-loaded passage: the primary action and its advantage come first, then the inputs, then the return categories, then the cost note. Every clause carries information, though the parenthetical enumerations make it heavier than strictly necessary.

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 tool with no output schema, the description compensates by listing what kinds of changes come back, and it covers cost, auth (license_key vs x402) and the incentive structure for last_trip. What remains unstated is granularity of the response (per-server grouping) and how 'silent changes' is determined, minor gaps for a read-only diff 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?

Schema coverage is 100%, so the baseline is 3. The description still adds value beyond the schema by enumerating the change categories returned (outages, recoveries, tools added/removed/changed, risk increases, silent changes) and by motivating the optional last_trip object as a data-quality contribution with a reward, which the schema only describes structurally.

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 — checking what changed across MCP servers since a date — with scope (up to 50 servers) and explicitly frames itself as the batch alternative to one-by-one checks, which separates it from siblings like preflight or watch.

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 says to use this 'in one call instead of one by one' and names the payment alternative (list_paid_tools). It also states the condition 'most answers are nothing changed', which sets expectations. It stops short of stating when NOT to use it (e.g., single-server checks or first-time setup).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare this is a non-read-only, open-world, idempotent, non-destructive operation, and the description adds substantial context beyond that: the two-step file-based verification flow, that verifying does not change measurement/ranking, and that it is free. That disclosure of mechanism and side-effect scope is exactly what the annotations cannot convey. It stops short of 5 only because host/auth prerequisites are implied rather than stated.

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 front-loaded with the when-to-use clause, then the mechanics, then the reassurance about ranking and cost. Every sentence contributes something, and there is no filler. It runs slightly long, which keeps it just shy of 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?

With no output schema, the description correctly compensates by explaining what the first call returns (a line of text for /.well-known/7maps-verify.txt) and the need to call again after placing the file. Combined with annotations that cover the safety profile, an agent has enough to invoke this correctly; only the precise confirmation semantics are left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both `server` and `note` with types, lengths, and constraints. The description's reference to 'add a short note for agents' echoes the note parameter but adds no syntax or format detail beyond it. The baseline of 3 is appropriate when the schema carries the parameter burden.

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+resource (verify ownership of an MCP server on 7Maps) and enumerates the concrete outcomes: owner-verified page, agent note, README badge. This is far more than a restatement of the name/title. It does not, however, explicitly distinguish itself from the adjacent submit_mcp_server sibling, leaving that inference to the agent.

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 clear trigger condition: 'Use this when the person you work for owns or runs an MCP server that is on the 7Maps map...' and lays out the intended use cases (verified badge, agent note, status badge). It does not name alternatives or state when NOT to use it versus submit_mcp_server, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: the call itself is free ("No charge"), payment is via x402/USDC on Base with no account required, and a license-key alternative exists. Return format is not described, but an output schema is present, so that gap is acceptable.

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 usage instruction is front-loaded in the first clause, followed by payment mechanics and the free-of-charge fact. The parenthetical about owner-approved budgets is dense but carries real information, and there is no filler sentence.

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, read-only discovery tool with an output schema, the description supplies everything an agent needs: what it returns (prices, plans, payment details), when to call it, and how the two payment paths work. Nothing necessary is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which is the baseline-4 case per the rubric. The description adds no parameter detail, but there is nothing to document, so no gap exists.

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 lists what each paid 7IT tool costs and the payment options (per-call USDC on Base via x402, or a monthly plan license key). The purpose is unambiguous. It does not explicitly contrast itself with any sibling tool, though none of the listed siblings appear to be pricing tools, so differentiation is largely unnecessary here.

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?

"Use this before calling a paid 7IT tool" gives an explicit trigger condition, which is strong context for when to call it. It also clarifies the prerequisite for the x402 path (an owner-approved budget, no account). It stops short of stating when NOT to use it or naming an alternative, so it falls just short of the top score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered; the description reinforces this with 'Never calls the server.' It adds genuinely new context: paid per check, the three-valued outcome (go/no_go/fix), and the goal of avoiding a failed round trip. It does not cover rate limits or failure handling, keeping it below 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?

Front-loaded with the usage instruction, then the checks, then the return and cost note. Each sentence carries information, though the list of validated checks in the first sentence is dense. Efficient overall with minimal padding.

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 usefully explains the return values (go, no_go, fix). Combined with cost disclosure, the usage trigger, and the non-invocation guarantee, it is complete enough for a 5-param tool with nested objects. The nested last_trip object's feedback semantics are left mostly to 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 description coverage is 100%, so all five parameters are already documented, establishing the baseline of 3. The description clarifies what the 'arguments' param is checked against (required, types, allowed values, unknown keys), which adds modest value, but it says nothing extra about last_trip or license_key beyond 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?

States a specific verb and resource: it preflights an MCP tool call, validating server reachability, auth, tool existence, and argument-schema conformance. The closing 'Never calls the server' sharply distinguishes it from actual invocation tools, and from siblings like route or tool_card. An agent can tell exactly what this does 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?

Gives an explicit trigger ('right before calling a tool on an MCP server you have not used today') and points to list_paid_tools for cost. The 'you have not used today' qualifier implicitly excludes already-used servers, so the when-not is present but not spelled out as a hard rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the sparse annotations: fixed-fields-only input, no free text, the fact that reports aggregate into a public server rating and incident alerts seen by every agent, and 'No charge' cost disclosure. Annotation readOnlyHint=false correctly aligns with a write/submission operation, and the description explains its downstream effect well, though it does not cover repeat-submission or idempotency behavior.

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 'Use this after...' trigger and structured logically. It is a bit dense with several clauses, but each sentence (constraint, aggregate effect, alternative, cost) carries distinct information 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?

For a 10-parameter telemetry submission tool with no output schema, the description covers the trigger, the input constraint, the consequence of reporting, and cost. Return-value behavior is not described, but the aggregate effect narrative largely compensates for a simple confirmation response.

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% and each of the 10 parameters is individually documented, so the schema does the heavy lifting. The description conceptually enumerates what to report (worked, why not, duration, match, surprises), which lightly reinforces the fields but adds no syntax or format detail beyond 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?

States a specific verb (report) and a well-scoped resource: the outcome of a call to an MCP server. The description immediately clarifies what is being reported (whether it worked, why not, duration, description match, surprises), so an agent can distinguish it from sibling tools 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 says when to use it (after calling a tool on an MCP server, especially one 7Maps pointed you to) and names an alternative mechanism (passing the same fields as last_trip on a paid call). It stops short of an explicit when-not-to-use, so it is strong but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: discloses the data sources (daily check of every remote server in the official MCP registry plus 30 days of history), the cost model ('paid per check'), the incentive for feedback (5 accepted reports earn 1 free call), and critically the safety boundary ('Reads the map only; never calls the server'). That last point strongly reinforces readOnlyHint/destructiveHint=false.

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-loads the when-to-use trigger, then the returned signals, then the local-server variant, then the cost/safety caveat. Dense and largely earned, though it is one run-on sentence with several stacked clauses that could be split.

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 enumerates the returned fields for both remote and local servers (up status, auth need, latency, tool risk breakdown, change recency, success probability, version, maintainers, install scripts), so an agent knows what it gets without calling. Nothing material 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 server/last_trip/license_key semantics are already fully documented in the schema. The description only adds that checks are paid and points to list_paid_tools; it does not explain the last_trip report object or what a license key unlocks. Baseline 3 is appropriate.

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 ('is it up, does it need sign-in...' about an MCP server before connecting) and even splits behavior by server type (remote registry server vs. local npm/PyPI package). It does not, however, differentiate itself from likely-overlapping siblings such as preflight or tool_card, so the agent must infer which check tool wins.

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 an explicit trigger ('before connecting to or calling any MCP server you have not used today, or before installing one that runs locally') which implies when not to use it, and routes pricing questions to list_paid_tools. No comparison against sibling preflight/tool_card, so the alternative-selection guidance is incomplete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already carrying readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, the description adds real context beyond them: it is 'Paid per task (see list_paid_tools)', it 'Reads the map only', and it discloses the return content (best server/tool, alternatives, servers to avoid). Cost and the least-privilege ranking rationale are genuinely useful disclosures.

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 dense single paragraph but front-loads the when-to-use trigger before the mechanism and billing notes. Each clause carries information (matching, ranking criteria, returns, cost), though the parenthetical ranking explanation could be tightened.

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 stating what is returned (best server and tool, alternatives, servers to avoid). It also covers the payment model and read-only scope. The nested last_trip reporting object is left to the schema, which is reasonable, but the description could mention it as a feedback loop.

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 every parameter including the nested last_trip object and the need enum is already documented in the schema. The description adds little parameter-level detail beyond restating that task matching and payment happen; baseline 3 is appropriate when the schema does the heavy lifting.

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 action and resource ('finds servers whose tools match the task and ranks them') and names its ranking criteria, so an agent knows this is a task-to-server routing tool. It references list_paid_tools for billing but does not distinguish itself from siblings like preflight or tool_card, which likely overlap in the discovery space.

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 an explicit trigger: 'Use this when you need a tool for a task and do not know which MCP server to use, or when several could do it.' That is a clear when-to-use condition. It lacks explicit when-not-to-use guidance relative to the other discovery-oriented siblings, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the operation is non-destructive, open-world, and idempotent, and the description adds substantial context beyond that: a 7-day observation window with checks every 6 hours, a 90% uptime bar, tool stability and description requirements, the fact that placement cannot be bought, that it is free, and what it returns (status page plus optional owner-verification token).

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 front-loaded with the usage trigger, then moves through input handling, acceptance criteria, and outputs in a logical order. Four sentences with almost no waste, though the trust-related clauses ('Placement cannot be bought', 'No charge') are two statements doing similar work.

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, yet the description says what is returned (status page, optional owner-verification token). Combined with the acceptance criteria, timing, and cost, an agent has everything needed to invoke this correctly against a fully documented six-parameter 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 description coverage is 100%, so the schema already documents all six parameters and the baseline would be 3. The description adds genuine meaning for `url` by explaining that a bare business domain is acceptable and that the usual endpoint paths will be probed — behavior the schema does not state.

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 — putting a new MCP server onto the 7Maps map that agents use to choose servers — and makes the audience and outcome explicit. It is trivially distinguishable from every sibling, which are all check_*, report_*, or list_* 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?

It gives a clear triggering condition: use when someone has built or runs an MCP server not in the official registry and wants agents to find it, or asks how to get listed. It does not name an alternative tool or state when not to use this one, but no sibling overlaps this submission flow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered; the description usefully adds the cost model (paid per server, see list_paid_tools) and the token-savings claim (70-90% fewer tokens) and confirms no map mutation ('Reads the map only'). It does not disclose rate limits or failure behavior, so not 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?

Front-loads the key routing instruction ('Use this instead of...') and packs the return shape, cost savings and payment note into three tight sentences with no filler. Dense 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?

With no output schema, the description correctly fills the gap by describing what each card contains (purpose, arguments with * markers, risk level, side effects, hash). Payment and filtering are covered; only edge behavior (failure modes, token accounting) is left implicit.

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 100%, so parameters are already documented; per the rubric this sets a baseline of 3. The description adds only light context ('Optionally only the named tools', payment pointer) and says nothing about the last_trip reporting object beyond what the schema already describes.

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 one compact card per tool for a named server (what it does, arguments with required ones marked *, risk level, side effects) plus a definition hash. This is clearly distinguishable from siblings like preflight or list_paid_tools without opening either 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 frames the selection condition: use it instead of loading full tool definitions when only choosing a tool or preparing a call, and points to list_paid_tools for payment. It does not state when NOT to use it (e.g. when full definitions are actually needed), so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 covered structurally. The description adds genuinely new behavioral context: it is paid per server, 'reads the map only' (implying no live server contact), and returns one of four per-tool states including risk escalation on changes.

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 mechanics, then cost and side-effect notes; every clause carries information. It is dense and slightly run-on, but no sentence is 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 compensates by enumerating the return classifications (unchanged, changed with risk rise, removed, new). Combined with annotations and 100% schema coverage, an agent has enough to call it correctly; the remaining gap is the exact shape of the returned report.

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 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining where the lock comes from ('as returned by watch or tool_card') and why last_trip exists ('keeps the map honest; 5 accepted reports earn 1 free call'). It does not clarify the last_trip fields' semantics further, which are already documented 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?

States a specific verb and resource ('check that an MCP server's tools are still the ones a person approved') and frames it with a concrete analogy ('like a lockfile'). The rug-pull framing and the per-tool outcome list make it distinguishable from siblings like tool_card, watch and changes_since.

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?

Clear trigger context: use it after approval, passing the lock you saved, to detect post-approval tool changes. It references watch and tool_card as the source of the lock and points to list_paid_tools for pricing, but it never explicitly says when not to use it or how it differs from changes_since/preflight.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds genuinely useful non-structured context: it detects silent changes made without a new server version, it is paid per check (pointing to list_paid_tools), and it 'reads the map only' — the cost and silent-change details are the real value here.

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 usage trigger, then capability, then the conditional follow-up, then cost and scope. Dense but every sentence carries information; minor redundancy between 'reads the map only' and the readOnlyHint annotation.

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, and the description does describe the return semantically (whether tools changed, whether risk rose). With 100% schema coverage and full annotations, the only real omission is any mention of the sibling changes_since, which would help an agent choose 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 100%, so server, approved_at, last_trip and license_key are already documented in the schema. The description only lightly gestures at approved_at ('since that date') and adds nothing about license_key or the last_trip reporting payload, so baseline 3 is appropriate.

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: it tells whether an approved MCP server's tools changed since a date and whether risk increased. Very concrete, but it never distinguishes itself from the near-identically named sibling 'changes_since', leaving ambiguity about which change-detection tool applies.

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 clear trigger ('before reusing an MCP server that a person approved earlier') and a conditional next action ('if the risk went up, ask the person to approve again'). It lacks any exclusion or named alternative such as changes_since, so the routing against siblings 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.