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 cover read-only, idempotent, non-destructive, closed-world. The description adds the billing model (paid per call, x402 vs license_key), that it 'reads the map only' (no live probing of servers), and the high likelihood of an empty result. It does not state rate limits or the 30-day window itself, which lives in 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?

Front-loaded with the use case and batched value proposition, followed by the cost caveat and read-only note. Dense but every clause carries information; only the 'instead of one by one' phrasing is slightly redundant with the batch framing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the return-value burden and does so by listing the change categories (outages, recoveries, tool adds/removes/changes, risk increases, silent changes). The nested last_trip reporting object is fully documented in the schema, and payment handling is covered. Slightly thin on the shape/format of the returned delta.

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 servers, since, last_trip, and license_key in detail, including the 30-day lookback and 50-item cap. The description echoes the two key parameters but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 what changed on MCP servers, in a single batch call instead of one by one. The batch framing distinguishes it from per-server siblings like my_server_report or watch, though no sibling is named directly. The parenthetical enumeration of change types makes the scope 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?

Gives clear context: use it with up to 50 servers plus your last check date to get a delta, and it names list_paid_tools for the pricing path. It also sets the expectation that most answers are 'nothing changed'. No explicit when-not or alternative-tool guidance beyond the one-by-one contrast.

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?

Beyond the annotations, it discloses the 5-minute re-check cadence, alert delivery on down/up via alert_url, that the owner secret is shown only once and required for later edits, and the one-time-code recovery mechanics. This is rich behavioral context an agent cannot infer from readOnlyHint/idempotentHint alone.

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 trigger condition and every sentence carries needed information about the multi-step verification, recovery, and alerting. It could be more scannable with structure, but given the tool's complexity little 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 explaining return values (proof options on first call, owner secret shown once) and the full call sequence. Nothing an agent needs to invoke this 6-parameter, multi-step tool 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 schema already documents each parameter and the baseline is 3. The description adds genuine value by explaining the sequencing and dependency between owner_secret, recover, and recover_check that the flat schema cannot convey.

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 (verify/claim ownership of an MCP server on 7Maps) and frames the trigger as the owner wanting a verified page, agent note, or status badge. It is clearly distinguishable from siblings like submit_mcp_server, my_server_report, and verify_lock.

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 explicit when-to-use conditions, the exact multi-step flow (first call returns proof options, call again to confirm), and the alternative recovery path (recover true, then recover_check). It even clarifies what the tool does NOT do (does not change measurement/ranking) and that there is no charge.

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?

Beyond the annotations, which already mark it as a safe read-only operation, the description discloses the search corpus size and freshness, the result metadata returned (read-only/change/high-risk estimate, server answering status, handshake time, token cost, page link), duplicate collapsing, and that there is no charge. This is unusually rich behavioral context for an agent deciding whether and how to invoke it.

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 definition is front-loaded with the core purpose and alternative, and most sentences earn their place by carrying useful selection or behavioral detail. It is dense and somewhat run-on, but not padded or repetitive.

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?

Given the complexity of searching over 200,000 tools and the presence of an output schema, the description is complete enough. It covers the search scope, filters, return-value highlights, deduplication behavior, cost, and the routing alternative that an agent needs 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 description coverage is 78%, so the schema already documents most parameters well. The description adds some filter semantics by mentioning read-only tools, servers answering now, and latency or token ceilings, but it does not add meaning beyond the schema for parameters like job, limit, payment, task_type, or agent_model. Baseline 3 is appropriate given the high schema coverage.

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: search every tool on every public MCP server on the 7Maps map to find a tool for a job. It clearly distinguishes this broad-discovery tool from the sibling routing tool 'route', which picks one server and tool for 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 explicitly says when to use this tool: 'when you need a tool for a job and do not know which MCP server has one.' It also names the alternative ('route') and the condition that selects it, leaving little ambiguity about tool choice.

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 cover safety (readOnly, idempotent, non-destructive, not open-world), so the description earns credit for adding non-obvious behavior: it reads the optional X-7Maps-Key header, degrades to a one-line notice when absent, is scoped to one person, and is free of charge. It does not describe latency or failure modes of the read itself, keeping it out of 5 territory.

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 trigger condition is front-loaded and the metrics are enumerated in one pass with no filler or marketing language. It is a dense run-on sentence, though, with phrases like 'an estimate of the tokens saved compared with finding the same thing out without 7Maps' that 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 carries the return-value burden and does so by listing every reported metric plus the no-key fallback, which is sufficient for an agent to call it correctly. It omits nothing critical, though it could note the response shape of the failure breakdown more concretely.

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 the single enum parameter is fully documented there, so the baseline is 3. The description implies all three windows are returned ('today, in the last 7 days and in the last 30 days') but never mentions the 'window' parameter or its role in choosing which period leads the response.

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-and-resource pairing (report personal 7Maps key usage) and enumerates exactly what is counted: calls, servers checked, token savings, failures avoided, average response time. Its scoping to 'that person's own counts' implicitly separates it from the server-wide sibling my_server_report, but no sibling is named explicitly, 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 the person you work for asks what 7Maps has done for them' gives an explicit triggering condition, and the fallback behavior without a key is spelled out. It does not name a competing tool (e.g. my_server_report or about_7maps) or any when-not-to-use condition, so it lacks the routing precision 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 readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real value by disclosing privacy scope ("Counts only, no agent identities"), the no-charge and no-routing-impact behavior, and that owner_key gates extra fields. It stops short of describing return shape or rate/refresh behavior, but it exceeds what the annotations alone convey.

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 use-condition, which is good, but the middle is a single long clause-chained sentence packing many metric types together. It is denser than it needs to be, and the metric list could be trimmed or bulleted without losing meaning.

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 carry return-value meaning, and it does list what comes back for both the public and owner_key cases, including the fallback of how to verify ownership. It lacks anything on response size/pagination or the exact shape, leaving a small gap for a tool with no output schema.

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

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

Schema coverage is 100%, so baseline is 3, but the description earns above baseline: it explains that owner_key (returned by claim_mcp_server) unlocks things like the words agents used, servers picked instead, failure reasons, uptime and tool changes, and that the 7/30-day window scopes the category counts. That is genuine semantic value beyond the schema text.

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 reports how agents search for and behave around a given MCP server on 7Maps, enumerating the metric families returned. It is clearly a server-owner analytics tool, though it never explicitly contrasts itself with close siblings like my_7maps_usage or my_server_report, 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?

"Use this when the person you work for owns an MCP server on the 7Maps map..." gives a clear triggering condition, and the owner_key branch tells the agent what to do when ownership is unverified, pointing at claim_mcp_server. There is no explicit when-not or exclusion against adjacent usage/admin siblings, which keeps it from 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false. The description adds value beyond these by stating the cost model ("Paid per check (see list_paid_tools)"), the exact return vocabulary (go, no_go, fix), and that it "Never calls the server." That cost and output-shape disclosure goes past what the annotations provide.

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 tightly packed sentences: the first front-loads the usage trigger and the four checks, the second covers the return values, cost, and the no-server-call guarantee. No sentence is wasted or redundant with the schema.

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 appropriately explains the verdict values (go/no_go/fix) and the surrounding workflow. It stops short of detailing what a fix payload contains beyond "what to change," a minor gap for a tool whose parameters are otherwise fully documented.

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%, including a fully documented nested last_trip object, so the schema already carries parameter meaning. The description only restates the arguments parameter ("the exact arguments you plan to send") and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 and scope: it checks that an MCP server answers, whether sign-in is needed, that the tool still exists, and that arguments match the schema. This is a distinct capability no sibling (tool_card, find_tool, verify_lock) plainly duplicates, though it does not explicitly contrast itself with them. An agent can tell what the tool 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?

"Use this right before calling a tool on an MCP server you have not used today, with the exact arguments you plan to send" gives a clear triggering condition and timing. It also routes payment questions to list_paid_tools. There is no explicit when-not guidance, but the gating condition is precise enough to act on.

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 flag this as a non-read-only, non-destructive write; the description adds genuinely new context: no charge, fixed fields only with no open text, anonymity of agent_model, and that reports aggregate into server ratings and confirmed incident alerts visible to all agents. The downstream propagation and cost profile are the kind of traits annotations cannot express. It omits what happens to a malformed or duplicate report (idempotentHint is 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?

Three front-loaded sentences that each carry information: usage trigger, reporting contract and privacy, then downstream effect and the alternative channel. The middle clause runs long and packs several ideas together, but nothing is 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?

For a 12-parameter write tool with full schema coverage, no output schema and informative annotations, the description covers purpose, cost, anonymity, and downstream consequence. The remaining gap is error behavior — what happens if required fields are missing or the same report is sent twice (idempotentHint is false).

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 earns a bump by framing the fields as questions the agent should answer (did it work, why not, how long, did the result match the description, did it do something unasked) and by flagging that only the task category is retained, never task text. It still adds no syntax or format guidance 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 — report how a call to an MCP server went — and enumerates exactly what is reported (success, failure reason, latency, description match, surprises). This is clearly distinguishable from siblings like tool_card, preflight, or road_conditions, which supply ratings rather than accept 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?

Gives an explicit trigger ('after calling a tool on an MCP server, especially one 7Maps pointed you to') and names an alternative channel ('you can also pass the same fields as last_trip on any paid 7Maps call'). It does not state when reporting is unnecessary or discouraged, so it falls short of a full 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; the description adds critical context beyond them, including 'paid per check', 'reads the map only; never calls the server', the daily-check cadence and 30-day history, and that risk/cost figures are automated estimates from public descriptions. These are behavior facts an agent cannot 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 primary usage constraint is front-loaded, which is good, but the body is a single dense run-on sentence packing many clauses (risk categories, history window, local-server fields) that is harder to scan than separate sentences would be. Content earns its place; structure does not.

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 5-parameter, nested-object tool with no output schema, the description is thorough about what it reports and the cost model. It stops short of describing the shape of the response (fields, confidence framing), which an agent would need to parse results, but overall it is complete enough to call 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 each parameter is already documented, including the server identifier formats and the last_trip sub-fields. The description adds only marginal semantics (contrasting remote vs local server inputs) and does not explain optional parameters like task_type or license_key beyond the schema. 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 names a specific verb+resource ('road_conditions' as the condition of an MCP server) and enumerates exactly what is reported: uptime, sign-in need, latency, read-only/approval/high-risk tool counts, tool-change timestamps, and success probability. It is clearly differentiated from siblings like preflight or tool_card by scoping to 'before connecting to any server you have not used today'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit trigger conditions are given: before connecting to or calling an unseen server, or before installing a locally-run package. It lacks named alternatives (e.g. when to prefer preflight or tool_card instead), so the routing is not fully closed, but the usage context is unambiguous.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description usefully reinforces this with 'Reads the map only' while adding non-obvious facts: pay-per-task billing, the pointer to list_paid_tools, and the shape of the return (best match, alternatives, servers to avoid). It does not mention rate limits, latency, or what happens when no server 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?

It is front-loaded with the trigger condition and the ranking logic before the cost and return-value notes; nearly every clause carries information. The long parenthetical about least privilege is dense but earns its place by defining the ranking criterion.

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 naming what is returned (best server and tool, alternatives, servers to avoid). It also flags billing and the feedback loop. The remaining gap is behavior when nothing matches or when the paid path is unavailable, which matters for a 7-parameter, nested-input 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% with rich enum and per-field descriptions, so the schema already carries parameter meaning. The description adds the conceptual basis for the ranking (works-chance, stability, least privilege) that motivates last_trip and need, and mentions the payment model behind the payment param, but gives no per-parameter detail of its own. Baseline 3 applies.

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 chain (finds matching servers, ranks them, returns the best server and tool) and the exact trigger ('you need a tool for a task and do not know which MCP server to use'). The ranking criteria (works-chance, stability, least privilege) make it distinguishable from lookup siblings like find_tool or tool_card even without naming 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 clear when-to-use conditions: no known server, or several candidates. It also discloses the cost model and points to list_paid_tools for pricing. It stops short of naming sibling alternatives (find_tool, preflight, tool_card) or stating when not to use this router, so an agent must infer the boundary itself.

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 past the annotations by disclosing the asynchronous acceptance process (observed every 6 hours for 7 days), the criteria for listing (reliable answers, stable tools, every tool described), that placement cannot be bought, that there is no charge, and that the call returns a status page plus an optional owner-verification token. The idempotentHint is corroborated by the 'tried endpoint paths' fallback 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 usage trigger, then the input flexibility, then the process and outcome — a logical order with almost no filler. It is dense but every sentence carries information; only the 'No charge' closing is slightly redundant with 'Placement cannot be bought'.

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 submission tool with no output schema, the description supplies everything an agent needs: eligibility, input fallback, observation window, acceptance criteria, cost, and the shape of the return (status page + optional verification token). Nothing material is left unexplained.

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, but the description adds genuine meaning: the url parameter accepts either a full server address or just a business domain, in which case 'the usual endpoint paths are tried'. That fallback semantics is not derivable from the schema's maxLength/minLength constraints.

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 on the 7Maps map — and scopes it to servers 'not in the official MCP registry', which implicitly separates it from the listing/report siblings. It never names a sibling (e.g. claim_mcp_server or my_server_report) explicitly, so an agent still has to infer which of the related server tools 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?

Clear triggering conditions are given: 'Use this when someone has built or runs an MCP server that is not in the official MCP registry... or asks how to get their server listed.' That covers the when. It does not state when NOT to use it or point to the alternative (claim_mcp_server) for servers already listed.

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/closed-world, so the bar is lower; the description adds genuinely useful context beyond them: 'Reads the map only', the paid-per-server model with a pointer to list_paid_tools, and the token-saving magnitude (70-90% fewer). It also sketches the card contents, though it omits return shape details.

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?

Four front-loaded sentences, each carrying distinct information (what it returns, why to prefer it, the optional filter, the cost/read-only note). Dense but without filler; the parenthetical list of card fields is the only slightly breathless part.

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 4-parameter read-only tool with no output schema, the description covers what the cards contain (compensating for the missing output schema), the optional tool filter, the cost model, and the read-only nature. The nested last_trip object is fully documented in the schema, so nothing critical 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's 'Optionally only the named tools' merely restates the schema's own description for tools, and the mention of payment lightly touches license_key. The last_trip object's rich schema text is not supplemented in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it returns one compact card per tool for a given server, containing what the tool does, its arguments (required marked *), risk level and side effects, plus a definition hash. It distinguishes itself from 'loading a server's full tool definitions' but does not explicitly differentiate itself from siblings like find_tool or preflight.

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 condition and an alternative: 'Use this instead of loading a server's full tool definitions when you only need to choose a tool or prepare a call.' It also routes to list_paid_tools for the payment model. There is no explicit when-not-to-use or sibling comparison beyond the generic full-tool-list alternative.

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 readOnly/idempotent/non-destructive, so the bar is lower, and the description adds genuinely useful context: it is paid per server, it 'reads the map only' (no server-side mutation), and it explains the per-tool result categories including risk rises. It does not describe failure modes or what happens if the lock is stale.

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

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

Dense but front-loaded: the purpose and the lock input appear first, followed by the output categories, the rationale (rug pulls), pricing, and the read-only guarantee. No sentence is wasted, though the run-on structure packs several ideas into one long 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?

With no output schema, the description compensates by enumerating the per-tool result states (unchanged, changed with risk rise, removed, new) and the cost/auth model is covered in the schema. For a nested-object, 4-parameter tool this is nearly complete, missing only edge-case behavior for malformed or partial locks.

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% and each parameter carries its own description, so the schema does the heavy lifting. The description adds provenance for the lock object (tool name to hash, as returned by watch or tool_card) but says nothing about server, last_trip, or license_key beyond what the schema already documents.

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 (verify/check) and resource (an MCP server's pinned tool list) and explicitly frames it as a lockfile comparison against a previously approved state. It differentiates itself from siblings by naming watch and tool_card as the sources of the lock and list_paid_tools for pricing.

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 scenario (confirming tools are still the ones a person approved, catching rug pulls after approval) and points to the siblings that produce the lock input. It does not spell out a when-not-to-use case or an alternative verifier, so it falls just 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 readOnly, idempotent and non-destructive, so safety is covered; the description adds real context on top – silent changes without a new version, risk escalation semantics, a per-check charge routed through list_paid_tools, and the 'reads the map only' scope. Lacks detail on return format, but that is secondary 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?

Dense but front-loaded: usage trigger first, then what it returns, then the escalation consequence, then cost and scope. Every sentence carries weight, though the risk-example parenthetical makes the middle clause slightly heavy.

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 four-parameter tool with a nested object and no output schema, the description conveys what the result substantively contains (changed tools, risk movement) and the cost/scope constraints. It stops short of describing the exact response fields, which is the only meaningful 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 100%, so all four parameters including the nested last_trip object are already documented. The description only lightly reinforces 'since that date' and the paid/license dimension; it adds little syntax or meaning beyond the schema, matching the baseline 3.

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 reports whether an approved MCP server's tools changed and whether risk rose, with concrete examples of risky change (deletes, pays, runs code). It does not, however, distinguish itself from close siblings like changes_since or verify_lock, so an agent cannot tell them apart from the text alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit trigger: 'Use this before reusing an MCP server that a person approved earlier,' plus a follow-up rule ('If the risk went up, ask the person to approve again before calling it'). Strong when-to-use guidance, but it names no alternative tool for the adjacent cases (e.g. when there is no prior approval).

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