7IT Solutions

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuine context beyond that: answers come only from the published profile, contain no prices or commitments, and quote requests are routed to a human who replies himself. It doesn't address latency or answer delivery format, but the content-scope and routing disclosure is substantive.

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 sentences, front-loaded with the usage trigger, then purpose, then boundaries. No filler; every clause carries distinct information (trigger, subject, content limits, escalation path).

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?

An output schema exists, so return values need no explanation. For a single-param, read-only tool, the description supplies the trigger, the topic scope, and the constraints on answers — 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 coverage is 100% and the 'question' parameter is fully documented, so baseline is 3. The description goes slightly further by indicating the topics questions may cover, adding intent-level meaning beyond the schema's syntax and length 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?

States a specific verb (ask a question) and resource (7IT Solutions) and enumerates the topics it handles, distinguishing it from describe_studio by name. An agent can tell exactly what this tool does versus the sibling it references.

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?

Opens with an explicit trigger ('Use this when the user has a specific question that describe_studio does not answer') and closes with a clear exclusion ('questions that need a quote are passed to Lior Aharonov'). Both when-to-use and when-not-to-use are stated, with the alternative named.

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/openWorld, and the description adds genuinely non-obvious behavior: a 20-60 second runtime, results rendered for a mobile viewport, and an explicit limitation that automated checks cover only part of WCAG and are not a legal opinion. It also discloses what the response contains (per-rule failures with WCAG mapping and element counts).

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 sentences, all front-loaded: trigger, mechanism, return shape, caveat. The caveat and timing sentences earn their place given the tool's legal-adjacent framing, though the comparison-to-7IT detail borders on promotional 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 one-parameter tool with rich annotations and an output schema, everything an agent needs is present: when to invoke it, what it actually runs, how long it takes, what comes back, and the important limitation on interpreting results. 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?

Single parameter with 100% schema description coverage, so the schema already documents 'url' and even supplies examples like 'example.com'. The description adds no syntax, normalization, or format detail beyond the schema, so the baseline of 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 ('Runs Google Lighthouse's automated accessibility checks ... on the page as a phone sees it') and names concrete outputs (score, failing rules, WCAG criterion, comparison to 7IT's study). This is readily distinguishable from siblings like check_ai_shopper_readiness or test_store_speed, which target different audits.

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 explicit triggering conditions: when someone asks whether a site 'is accessible, meets WCAG, or could face an ADA accessibility complaint.' That is clear context for selection, but it never names an alternative tool or states when this would be the wrong choice, so it stops short of full when/when-not guidance.

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 readOnly, idempotent, openWorld, and non-destructive hints. The description adds value beyond that: it uses an identified crawler that respects robots.txt, it returns gaps with fixes benchmarked against a study, and it names the specific inputs it examines. It does not state rate limits or runtime expectations, but the behavioral profile is well-communicated.

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 sentences, front-loaded with the trigger and then enumerated checks. Efficient and well-organized. Slightly dense with the long list of structured-data fields, but every element earns its place by telling the agent what is inspected.

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?

The tool is moderately complex, with two parameters, full schema coverage, and an output schema that presumably explains return values. The description covers what is checked, how (identified crawler respecting robots.txt), and what is returned (gaps with fixes plus benchmark comparison). This is nearly complete, though it doesn't explicitly mention that the output schema defines the return structure.

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 url and product_url, including the fallback behavior for product_url. The description adds no additional syntax, format, or constraint details beyond what the schema provides, 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 (check) and resource (AI shopper readiness of a store), and enumerates exactly what it inspects: robots.txt AI vs training crawlers, llms.txt, agents.md, UCP discovery file, and product structured data. This distinguishes it from siblings like check_accessibility or test_store_speed, which cover different readiness dimensions.

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?

Provides a clear usage trigger: 'Use this when someone asks whether ChatGPT, Claude, Perplexity or other AI shopping agents can find, read and recommend their online store's products.' Context is explicit, but it does not name sibling tools or say when NOT to use it versus check_accessibility or check_app_security.

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 the description adds real behavioral context beyond them: it reads only the public headers any browser receives and never logs in, submits forms, calls the app's APIs, or reads data for secrets. That precisely bounds the blast radius and honesty of the result.

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?

Usage trigger is front-loaded, followed by scope limits and then the checklist of headers examined. The third sentence's parenthetical enumeration is long, but each item earns its place by telling the agent what the tool actually reports.

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 an output schema present, return values need not be described, and the description covers scope, capability limits, and what is inspected. Nothing an agent needs to decide to call this tool or to interpret its domain 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 coverage is 100% and the single url parameter is already documented in the schema with format examples, so a baseline of 3 applies. The description adds no further syntax, normalization, or validation detail about the URL beyond what the schema provides.

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 (check a public web app's security hygiene) and enumerates exactly what is inspected: baseline browser protections and publicly served source maps. It implicitly separates itself from the deeper sibling deep_scan_app by framing this as a header-level hygiene check rather than a scan.

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 trigger conditions (someone asks whether a site is secure, safe to launch, or missing security headers) and clear exclusions (not a penetration test, cannot see behind a login). It stops short of naming an alternative sibling to route to when those conditions fail, so it is strong but not fully explicit about alternatives.

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, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds meaningful behavioral context beyond annotations: it discloses that it reads only public DNS records, sends no email, requires no access, and returns what is missing plus an exact fix compared to a reference study. This is useful transparency, though it stops short of describing output structure (which the output schema covers).

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 trigger scenarios then the mechanism in a single dense sentence. Slightly verbose with the parenthetical record list and the 7IT comparison, but every element conveys actionable information, not 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?

An output schema exists, so return-value detail is not required. Combined with annotations covering the safety profile and a fully documented parameter, the description provides complete context for an agent to invoke this 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% (the single 'url' parameter is documented with an example). The description says it reads a 'domain' but doesn't clarify whether a full URL or just the domain is expected, which the schema already addresses. 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?

States a specific verb (reads/checks) and resource (domain's public DNS records: SPF, DKIM, DMARC, BIMI, MX), and lists the exact records inspected. Clearly distinguishable from siblings like check_app_security, check_accessibility, or check_ai_shopper_readiness, which target different concerns.

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?

Opens with three concrete trigger scenarios: spam delivery, spoofing/phishing protection, and compliance with Gmail/Yahoo/Outlook bulk sender rules. This tells the agent exactly when to invoke this tool over alternatives.

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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description still adds substantial behavior: never contacts the app's database, never writes, never stores/logs/returns key values, and only reports the PATH or KIND of a finding. It also discloses the unusual two-call ownership-verification handshake, which no annotation conveys.

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 long but dense and front-loaded: the trigger comes first, then scope, then safety guarantees, then the call sequence. Nearly every sentence carries new information, though the single paragraph could be broken up for faster scanning.

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 2-param probe tool with an output schema, it covers everything an agent needs: when to call, the sibling alternative, the two-step ownership flow, safety guarantees, and what kinds of findings are returned. Nothing critical is left to inference.

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 goes further by explaining the lifecycle of 'check' — the first call returns a one-time code and check id, the code is placed on the app, and the second call uses that id to actually run the scan. That adds meaning beyond the schema's terse field note.

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+resource (deep security scan of an app) and enumerates exactly what it looks for: exposed .env, .git, directory listing, source maps, and secret keys shipped to the browser. It explicitly positions itself against the sibling check_app_security as 'a deeper security scan'.

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?

Names the trigger condition ('when the user, or the agent building the app, wants to check an app they control... before launch'), names the alternative tool and how this differs, and gives the full when-to-use precondition (ownership must be provable on the target app).

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 safety profile is covered. The description adds useful non-annotation context: the profile is factual, includes links to published/verifiable proof, and explicitly contains no prices.

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 conditions are front-loaded, but the text is bloated and repetitive: it restates the 'use this when...' guidance twice and re-lists the service areas across two long run-on sentences. It could lose roughly a third of its length without losing information.

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 an output schema present, the description need not enumerate return fields, yet it describes the returned content anyway (services, fit criteria, audit checks, proof links, no prices), which is more than sufficient. Nothing an agent needs to call 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% — the single 'focus' enum parameter is fully documented in the schema with its options and default. The description never mentions 'focus' and adds no syntax or interpretation beyond it, so 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 resource: it returns a factual profile of 7IT Solutions (who runs it, services, ownership, proof). An agent can tell what it produces. However, it never names or contrasts itself with the obvious sibling ask_7it, so the distinction between 'describe the studio' and 'ask the studio a question' must be inferred.

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 several concrete trigger conditions ('who 7IT is', 'whether it fits their project', 'looking for a developer to review or take over an AI-built app'). This is clear usage context, but there is no statement of when NOT to use it and no alternative tool is named for overlapping questions.

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 a safe read-only, idempotent, non-destructive profile, so the safety burden is lifted. The description adds genuine behavioral context beyond that: it defines the automation-eligible share ('copying between systems, not judgment'), pins the break-even horizons (12 and 6 months), and discloses the default $47/hr with its BLS source. It stops short of noting scaling limits or edge-case handling.

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 when-to-use trigger is front-loaded in the first sentence, followed by a compact enumeration of computed outputs. Two parentheticals (the judgment/copying distinction and the BLS citation) are load-bearing rather than filler, though the second sentence runs long.

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?

An output schema exists, so return-format explanation is unnecessary. Purpose, trigger, methodology, defaults, and the definition of the key derived ratio are all present, leaving nothing an agent needs in order to invoke this computation 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?

With schema coverage at 50%, the description is expected to compensate, and it does on the key points: it justifies the default hourly cost ($47, US private-industry average) and clarifies the semantic distinction that drives copying_share ('copying between systems, not judgment'). It also states that only provided figures are used, which clarifies the derived-output behavior of the tasks array.

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: calculating what a repetitive task costs a team and whether automation is worth the money. It enumerates the concrete outputs (hours/month, cost/year, automatable share, break-even budget at 12 and 6 months), so an agent knows exactly what this produces 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?

It gives an explicit situational trigger: 'Use this when someone wants to know what a repetitive task costs their team, or whether automating it is worth the money.' No alternatives or exclusions are named, but the sibling list contains no comparable ROI/cost tool to route against, so the absence is inconsequential.

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 read-only, idempotent, non-destructive and non-open-world, so the safety question is covered. The description still adds real behavioral context: results carry an automated capability/risk estimate, live server reachability, handshake latency, tool-list token cost, duplicate tools across servers are collapsed, and it is free. It stops short of describing result shape or pagination, though an output schema exists.

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?

Usage condition and core behavior are front-loaded, and the closing sentence routes to the alternative. The opening sentence is long and clause-heavy, packing scope, outputs and filters into one breath, but almost every clause carries information an agent needs.

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 7-parameter search tool with an output schema, the description covers scope, trust signals, dedup, cost and the sibling alternative. Remaining gaps are minor: how payment terms surface in results and the interaction between the default filters (answering_now true, may any) are left 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 coverage is 71%, and the description gestures at the filter set ('read-only tools, servers answering now, a latency or token ceiling') without adding syntax or semantics for max_handshake_ms, max_tool_list_tokens or limit. Payment filtering is only implied by 'No charge'. The schema carries most of the parameter meaning, so a baseline 3 fits.

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 concrete verb and resource ('searches every tool of every public MCP server on the 7Maps map') and quantifies scope with 'over 200,000 tools, probed daily'. It also explicitly distinguishes itself from the sibling 'route', which picks a server for you instead of returning ranked matches.

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 opens with the exact triggering condition ('when you need a tool for a job and do not know which MCP server has one') and closes with the alternative and the condition that selects it ('To have 7Maps pick one server and tool for you with alternatives, use route'). Both when-to-use and when-to-use-something-else are stated.

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), so the bar is lower. The description adds genuinely useful content-level context — that the response includes every check with its rationale, grouped in order, plus usage notes and the source guide. It stops short of noting error behavior for an invalid slug.

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, zero waste. The precondition ('after list_field_kits') is front-loaded before the return-shape detail.

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?

Output schema exists, so return values needn't be spelled out, yet the description helpfully summarizes them. For a single-param, read-only lookup, everything needed to call it correctly is present.

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 parameter is fully documented in the schema. The description's 'pass the slug from list_field_kits or words from the title' largely restates the schema's slug-or-title guidance, so it adds little beyond the baseline.

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: 'read one checklist in full' returning 'one 7IT Field Kit in full.' This is clearly distinguishable from the sibling list_field_kits, which the description explicitly names as the preceding step.

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 prescribes the workflow: 'Use this after list_field_kits.' It names the alternative tool and the condition that routes to this one, leaving nothing to inference about when to call it.

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 safety is covered. The description adds genuinely new behavioral context: it is a fixed panel of 100 stores, week-by-week, medians only with no store named, and the response includes a source link — all constraints an agent would otherwise have to guess.

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 the trigger condition, then the payload. Every clause carries information (metrics list, panel definition, aggregation caveat); nothing is redundant 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?

An output schema exists so return-value structure needn't be described, and the description still covers scope, panel, granularity, aggregation level, and provenance. Nothing an agent needs to call 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no filtering or scoping input is needed.

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

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

States a specific verb+resource ('Returns 7IT's weekly US Store Speed Index') and enumerates the exact metrics returned, so an agent can distinguish it from test_store_speed, which presumably tests one store rather than reporting an aggregate panel.

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?

Opens with an explicit trigger: 'Use this when someone asks how fast US online stores are right now, or wants a current benchmark to compare a store against.' Clear context, but it never names test_store_speed as the alternative for a single-store measurement, leaving the sibling routing to inference.

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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds the item shape (title, one-line purpose, check count, link) and the optional topic filter, but that is largely output detail that the output schema already carries.

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 well, but the "working checklists" framing is repeated across two sentences and the domain list is enumerated twice in adjacent clauses, which pads rather than clarifies.

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 single-optional-param read-only listing tool with a full output schema and rich annotations, the description supplies enough context to call it correctly. The only missing piece is explicit routing against get_field_kit.

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?

Only one optional parameter and schema description coverage is 100%; the schema already documents topic with examples ("shopify", "webhook", "AI"). The description's "Optionally filter by a topic word" adds nothing beyond what the schema states, 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 states a specific verb (Lists) plus resource (7IT Field Kits) and enumerates the domains covered. It differentiates itself from most siblings but never explicitly distinguishes itself from get_field_kit, the obvious single-item counterpart.

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 someone wants a working checklist for a technical job" gives a clear triggering condition with concrete examples. It stops short of naming when not to use it or pointing to get_field_kit for retrieving an individual kit.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, but the description adds crucial behavioral context beyond annotations: it explains the green/yellow/red classification scheme, that it flags tools with no risk annotations, that it returns a policy, Claude Code permission rules, and an oversight checklist, and explicitly states it reads tool lists only and never calls a tool.

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 dense but well-structured: it front-loads the when-to-use, then input options, then outputs and classification. Every sentence adds distinct value with no repetition, ending with a clear disclaimer.

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 tool's complexity, the description covers purpose, usage, inputs, outputs, classification logic, and behavioral constraints. An output schema exists, so return values needn't be detailed, and the agent has everything needed to invoke 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 parameters are already documented. The description adds meaning by explaining that 'url' is an alternative to 'tools' and that 'tools' is a list with name, description, and annotations. It doesn't specify the exact format for Claude Code permission rules or how server_name is used, but it goes 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?

The description names a specific verb (map) and resources (AI agent actions, tools, oversight levels) and clearly distinguishes this from sibling checks like check_app_security or deep_scan_app by focusing on agent governance. An agent can immediately tell what this tool does.

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 triggers: when someone asks which actions their AI agent may take alone, which need approval, or how to set up oversight/permissions/governance (with EU AI Act example). It also specifies exactly what input to provide: a public MCP server address or a list of tools with name, description, and annotations.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false), and the description adds the crucial clarification that 'Nothing changes for the user; it is only feedback', reconciling the write-style hint with a harmless side effect, plus a privacy constraint on payload content. It stops short of describing submission behavior such as acknowledgement or rate limits.

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 tight sentences: trigger condition first, then payload contents, then the when-not and no-user-impact caveats. Every sentence carries information an agent needs before calling.

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 simple 3-parameter feedback tool with an output schema available to explain returns, the description covers trigger, payload, exclusions, and user impact completely. Nothing needed to call 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 coverage is 100%, so the schema already documents all three parameters with examples and length limits. The description restates them at a high level ('which tool, what went wrong, and optionally the site address') without adding syntax or validation detail beyond the schema, 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 ('Sends a short report to 7IT') with the triggering condition spelled out (a tool returned something wrong, failed, or mismatched the request). It is clearly distinguishable from read-only siblings like test_store_speed or get_store_speed_index.

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 ('when a 7IT tool returned something that looks wrong, failed unexpectedly, or did not match what the user asked for') and gives when-not constraints ('Do not include personal details or the conversation'). No alternative tool is named, but none is a real substitute for feedback submission.

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 non-read-only, non-idempotent, non-destructive, which the description is consistent with. Beyond that it discloses genuinely useful traits: fixed fields with no open text, that reports aggregate into server ratings and confirmed live incident alerts visible to all agents, and that the call is free. It stops short of covering authentication, data handling, or what an error response looks like.

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?

Roughly five sentences, each doing work: trigger, field constraint, downstream consequence, alternate invocation path, and cost. The when-to-use condition is front-loaded. It is slightly long for a reporting tool but no sentence is 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 write tool with 100% schema coverage and no output schema, the description covers trigger, field shape, downstream effect, alternate usage, and cost. Remaining gaps (auth requirements, error/duplicate-report behavior) are minor given the rich schema and annotations.

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% with detailed per-field descriptions and two enums, so the schema already carries the load (baseline 3). The description adds framing value by grouping the fields semantically (outcome, failure reason, latency, description match, unrequested behavior) and by stating the constraint that only fixed fields, no free text, are accepted.

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: report how a call to an MCP server went, including the exact dimensions to report (worked, why not, latency, description match, surprises). It is clearly a post-call feedback tool. However, it never distinguishes itself from close siblings like report_problem 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 after calling a tool on an MCP server (especially one 7Maps pointed you to)" gives a clear trigger condition, and it names an alternative path (passing the same fields as last_trip on a paid 7Maps call). What is missing is any explicit exclusion telling the agent when to prefer report_problem or my_server_report instead.

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. The description adds useful behavioral context beyond those: it discloses the return format ('best matches with a short excerpt and a link to cite') and the closed corpus scope (7IT Solutions' guides and articles).

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 sentences, front-loaded with the usage condition, followed by search scope and return format. The middle sentence contains a long enumeration, but every clause is informative and directly aids query formation; no sentence is 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?

Given the rich annotations, 100% schema coverage, and presence of an output schema, the description supplies everything an agent needs: when to invoke it, what corpus it searches, and what it returns. No critical gaps remain for this read-only search 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 description coverage is 100%, so the input schema already fully documents 'query' and 'limit' including examples and constraints. The description does not add any syntax, format, or behavioral meaning for these parameters beyond what the schema provides, making the baseline 3 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 ('Searches') and resource ('7IT Solutions' guides and articles') and enumerates topical scope. This clearly distinguishes it from sibling tools like check_app_security or test_store_speed, which perform different operations.

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?

Provides clear context for when to use it: 'when the user is weighing a software, eCommerce, automation or AI decision and a cited article would help.' It does not name alternatives (e.g., ask_7it) or state when not to use it, so it falls short of the explicit routing seen in 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?

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 readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds what annotations cannot: an expected runtime ("Takes 20 to 60 seconds") and an input constraint ("Only public web addresses are accepted"), plus what the result will contain.

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 and core behavior are front-loaded in the first sentence, and the cost/time caveats are placed last. The middle enumeration of result fields (score, main content, layout shift, third-party apps, platform, fixes) is slightly long and partly duplicates the output schema, but each item is informative 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 two-parameter read-only analysis tool with an output schema, an agent has everything needed: trigger conditions, URL constraint, competitor limit, latency expectation, and an overview of the returned analysis. No gaps remain that would cause a misinvocation.

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 both `url` and `competitors` are already documented in the schema. The description restates that competitors are optional and capped at two for a side-by-side comparison, which matches maxItems: 2 without adding new syntax or format guidance. 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?

Names a specific verb and resource ("Runs Google PageSpeed Insights (mobile lab test) on a public online store or website") plus the exact output domain. The mobile-lab framing and public-URL scope distinguish it from the sibling get_store_speed_index 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?

"Use this when someone asks how fast a website or online store loads on a phone, why it is slow, or how it compares with a competitor" gives concrete trigger conditions and covers the comparison case. It stops short of naming an explicit alternative or exclusion (e.g., when to prefer get_store_speed_index instead), so it is clear context rather than full when/when-not routing.

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