Server Quality Checklist

Tool Scores

• gsc_pagesA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe to read. The description adds context that it focuses on high-impression low-CTR pages and mentions the ability to fix files in the editor, which implies editing capability but aligns with the read-only hint (edits happen in the editor, not via the tool). It doesn't provide additional behavioral details beyond schema, but given annotations, a 3 is appropriate.

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

  Conciseness4/5

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

  The description is two sentences, efficient and front-loaded with the core purpose. It includes a practical use case (fixing underselling titles/descriptions) and a note about being free, all without waste. Slightly less structured than the top-tier example, but still concise.

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

  Completeness4/5

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

  The tool is simple with one optional param, no output schema, and good annotations. The description covers the purpose, use case, and editing capability, which is sufficient for a read-only list tool. It lacks explicit mention of what the return data looks like, but that's acceptable given the output schema is absent and the tool is straightforward.

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

  Parameters3/5

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

  The schema covers 100% of the parameter (range_days) with a description indicating 28 or 90. The tool description adds no additional meaning beyond the schema, so baseline 3 applies. The param is simple and well-documented, so no extra explanation is needed.

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

  Purpose4/5

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

  The description clearly states the tool lists a user's pages ranked by search performance, with a specific focus on high-impression low-CTR pages and the ability to fix them in the editor. It distinguishes itself from sibling tools like gsc_overview and gsc_queries by focusing on pages and actionable title/description fixes, though it doesn't explicitly name an alternative.

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

  Usage Guidelines3/5

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

  The description implies the tool is used for identifying and fixing underperforming pages' titles/descriptions, but it doesn't explicitly state when to use it over siblings (e.g., gsc_queries for query-level analysis). It mentions it's free and uses the user's own data, but no exclusions or alternative tool mentions are provided.

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

• research_brand_lookupA
  4/5.0
  Behavior4/5

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

  No annotation contradiction: readOnlyHint=false and destructiveHint=false are consistent with a credit-consuming lookup that does not alert or destroy. The description usefully adds that the tool costs credits and that cached results are free, going beyond the annotations enough to inform agent/user expectations.

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

  Conciseness5/5

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

  The description is compact and front-loaded: it immediately states what the brand lookup measures, then gives a clear usage trigger, then credit/caching note. Every sentence earns its place with no wasted detail.

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

  Completeness4/5

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

  For a single-parameter lookup with no output schema, the description provides enough context: what is returned (platforms, mention counts, entities), when to invoke it, and cost implications. It could be slightly more explicit about the response format, but the tool's behavior is otherwise well covered.

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

  Parameters3/5

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

  There is only one parameter, 'brand', and the schema already explains it as 'Brand or domain'. The description shows why the brand is needed by the tool's purpose but does not add special format, alias, or filtering details. Schema description coverage is 100%, so the baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the subject: how AI assistants like ChatGPT cite a brand, including platforms, mention counts, and associated entities. It distinguishes itself from sibling research tools by focusing on AI assistant visibility, though it lacks a direct imperative verb such as 'returns' or 'looks up'.

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

  Usage Guidelines4/5

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

  Explicitly gives a concrete trigger: use when the user asks 'does AI recommend us/them?'. It also adds credit-cost guidance and mentions cached results are free. It does not explicitly mention when not to use this tool or name alternatives, so it falls 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.

• gsc_queriesA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context (data is free and from the user's own connected Search Console), which elaborates on the data source but does not disclose any additional behaviors like response structure or rate limits. Since annotations carry most of the burden, a score of 3 is appropriate.

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

  Conciseness5/5

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

  Two sentences, zero waste. The first sentence front-loads the core purpose and data fields, the second sentence provides concrete usage scenarios. Every word earns its place, making it highly concise and well-structured.

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

  Completeness5/5

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

  For a simple read-only tool with one optional parameter and no output schema, the description is complete. It explains what data is returned, when to use it, and why it matters (verification after edits). No essential information is missing for an agent to decide and invoke the tool correctly.

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

  Parameters3/5

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

  The schema description for range_days is complete ('28 (default) or 90'), covering 100% of the parameter semantic. The description does not mention the parameter at all, but the schema already does the heavy lifting. No additional value is added beyond the schema, so the baseline of 3 is correct.

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

  Purpose5/5

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

  The description clearly states the tool returns the user's real ranking keywords with position, clicks and CTR, and explicitly ties it to content decisions and page optimization. It distinguishes itself from siblings like gsc_pages (which likely handles page-level data) by focusing on keyword queries and even provides a concrete example (position 5-20).

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

  Usage Guidelines4/5

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

  The description provides explicit when-to-use guidance: 'use when deciding what to write or which page to improve' and 'After you edit a page, this is how you verify it moved.' It does not mention when not to use it or name alternative tools, but the context is clear and actionable. This is strong but not exhaustive.

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

• get_traceA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable context: the tool is free and provides polling guidance, which helps agents understand rate limits and avoid abuse. However, it doesn't detail what fields the status response includes, but that's minor given annotations.

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

  Conciseness5/5

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

  The description is extremely concise—three short sentences, each adding value: purpose, workflow, and polling guidance. No fluff, perfectly efficient.

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

  Completeness4/5

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

  Given the tool's simplicity (one parameter, no output schema), the description is nearly complete. It covers the workflow and usage constraints. It doesn't mention what the response contains (e.g., status values), but that's not critical for a polling tool and the output schema is absent, so a 4 is appropriate.

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

  Parameters3/5

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

  The input schema already provides full coverage for the single parameter (job_id with description 'Job id returned by start_trace'). The description adds no additional parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool polls a trace started with start_trace, using the verb 'poll' and specifying the resource (a running trace). It distinguishes itself from start_trace and read_report by indicating its role in the workflow, though it could explicitly mention it returns status updates.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use it (after start_trace) and when not to (when status is done, use read_report). It also provides polling interval guidance (every 10-15s, not tight loop), which is clear usage direction.

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

• gsc_overviewA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool will indicate if GSC is not connected, which is a useful behavioral cue. It also notes the tool is free, but that's more of a commercial detail than behavior. Overall, it provides context beyond the annotations without contradicting them.

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

  Conciseness5/5

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

  The description is two sentences, with the most important usage guidance front-loaded ('Use this before touching SEO'). It packs purpose, specific metrics, prerequisite, and error behavior without redundancy. Every sentence earns its place.

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

  Completeness5/5

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

  For a simple tool with 0 required parameters, no output schema, and read-only annotations, the description fully covers what the tool does, what data it returns, who it applies to (user's own site), and the prerequisite connection status. No further details are needed for the agent to decide when and how to invoke it.

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

  Parameters3/5

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

  There is only one parameter (range_days) with schema description coverage at 100% (it states '28 (default) or 90'). The description does not add any additional meaning or constraints 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.

  Purpose5/5

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

  The description clearly states the tool provides an overview of Google Search Console data (clicks/impressions trend, device split, period comparison) for the user's own site. It distinguishes from siblings like gsc_pages and gsc_queries by positioning itself as a general overview and claiming 'numbers no other tool has.' The verb is implied ('use before touching SEO') but the resource and scope are specific.

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

  Usage Guidelines4/5

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

  It explicitly says when to use it: 'before touching SEO on the user's own site.' It mentions a prerequisite (GSC connected at tracetify.com/dashboard/gsc) and that the tool will report if not connected. It does not explicitly name alternative tools or exclude use cases, but the timing and context are clear enough.

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

• research_competitorsA
  4.3/5.0
  Behavior4/5

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

  With only generic annotations (readOnlyHint=false, destructiveHint=false), the description adds meaningful behavioral context: it costs credits, cached results are free, and domains already looked up via research_domain_overview are free. It also tells the agent that results indicate whether a full growth report already exists. This goes beyond the schema and annotations, though it does not discuss auth or other side effects.

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

  Conciseness5/5

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

  The description is three sentences that front-load the output definition, then give usage guidance, then cost/caching behavior. Every sentence adds distinct value with no filler or repetition of the schema.

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

  Completeness5/5

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

  For a one-parameter tool with no output schema, the description covers the output fields, the use case, cost behavior, and the follow-up path to read_report. It is sufficiently complete for an agent to invoke and interpret the tool correctly.

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

  Parameters3/5

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

  The schema already provides 100% coverage for the single `domain` parameter with an example ('notion.so'). The description only refers to it as the 'target' and does not add new formats, constraints, or meaning beyond what the schema communicates, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly identifies the resource: 'domains fighting a target for the same search terms,' and lists the exact output fields (shared-keyword count, keyword totals, average rank). This distinguishes it from siblings like research_domain_overview and research_backlinks.

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

  Usage Guidelines4/5

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

  It explicitly states when to use the tool: 'Use when the user asks who their competitors are, or who a company is up against.' It also offers a clear alternative by telling the agent to use read_report for existing growth reports instead. It does not enumerate exclusions for every sibling, but the context is strong.

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

• site_audit_getA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'free to read' and describes that it polls until finished, implying possible non-immediate response. It also clarifies that it returns an issue list grouped by severity with affected URLs, which is useful behavioral context. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is a single, information-dense sentence that front-loads the purpose and provides actionable guidance without fluff.

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

  Completeness5/5

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

  With a simple tool (1 param, no output schema), the description covers key aspects: what it does, when to use it (after site_audit_start), what the result looks like, and how to proceed. Annotations cover behavioral safety, and the description adds polling and workflow context.

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

  Parameters3/5

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

  The single parameter audit_id is fully described in the schema ('Audit id from site_audit_start') and the description also references site_audit_start, reinforcing its source. Schema coverage is 100%, so the description doesn't need to add much. It meets the baseline of 3.

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

  Purpose5/5

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

  The description clearly states the tool polls an audit started with site_audit_start and returns the issue list grouped by severity with affected URLs. It explicitly connects to the sibling tool site_audit_start, distinguishing its purpose and scope.

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

  Usage Guidelines4/5

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

  It explicitly tells when to use (after site_audit_start) and suggests a workflow ('work through it top-down and re-run after fixes'). However, it does not explicitly state when NOT to use it or mention alternatives, but it is clear enough.

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

• backlink_directoriesA
  4.5/5.0
  Behavior4/5

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

  Annotations only indicate readOnlyHint=false and destructiveHint=false, but the description adds valuable behavioral context: it mentions credit cost per day and free repeat calls, plus data curation (hand-verified, dead/nofollow removed). This goes beyond the annotations and provides practical operational details without contradicting them.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the core function, followed by usage context, data quality, and cost behavior. No redundant phrasing, every sentence earns its place. The structure is efficient and easy to scan.

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

  Completeness5/5

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

  Despite having no parameters, no output schema, and minimal annotations, the description is remarkably complete for a simple list-retrieval tool. It covers what the data is, when to use it, how to filter it, and cost implications. No additional needed context appears missing.

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

  Parameters4/5

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

  There are zero parameters, so the description doesn't need to explain them. It mentions client-side filtering capabilities, which implies no parameters are required and the data is meant to be filtered locally. This aligns with the schema's empty fields and adds a hint about usage, so a baseline of 4 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool provides a hand-verified list of directories and launch platforms that give real backlinks. It specifies the verb (list) and the resource (directories/launch platforms), and distinguishes from sibling tools like research_backlinks by focusing on a curated directory list rather than analysis.

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

  Usage Guidelines4/5

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

  Explicitly says 'Use when the user wants backlinks or launch exposure for a new product' and mentions filtering client-side. It gives clear context for when to invoke, though it doesn't explicitly name alternative tools or say when not to use it. The guidance is sufficient but lacks exclusions.

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

• research_backlinksA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate the tool is not destructive, and the description goes beyond by disclosing credit costs and cached-result behavior. It does not fully clarify the non-readOnly annotation, but the credit cost and research nature are sufficiently transparent for usage.

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

  Conciseness5/5

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

  Three sentences, each adding value: the first defines outputs, the second gives use cases, and the third covers cost and a related tool. No wasted words, and the most relevant information appears first.

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

  Completeness5/5

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

  For a simple single-parameter research tool with no output schema, the description covers what the tool returns, when to use it, cost implications, cache behavior, and a complementary sibling tool. This is sufficient context for an agent to select and invoke it correctly.

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

  Parameters3/5

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

  The schema covers the lone parameter 'domain' fully with 'Domain to inspect.' The description reinforces the domain concept but adds little beyond what the schema already states. This is acceptable given the 100% schema coverage.

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

  Purpose5/5

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

  The description clearly explains the tool's purpose: showing who links to a domain, including referring domains, authority, and anchor texts. It distinguishes itself from siblings by focusing on link data and explicitly contrasts with backlink_directories.

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

  Usage Guidelines5/5

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

  The description states when to use the tool ('when planning link building or judging how defensible a competitor's ranking is') and points to a complementary tool (backlink_directories) for related but distinct needs. It also includes practical cost guidance about credits and caching.

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

• research_domain_overviewA
  4.5/5.0
  Behavior4/5

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

  The description adds significant context beyond annotations: it costs credits, cached results are free, and repeated queries within a week hit the cache. This discloses consumption behavior and non-obvious constraints. However, it does not explicitly state whether the operation is read-only, and annotations show readOnlyHint=false, which could be ambiguous, but nothing contradicts.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core output, then usage, cost, and alternative. Every sentence adds value with no redundancy or filler.

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

  Completeness5/5

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

  For a tool with a single parameter and no output schema, the description fully covers purpose, key alternatives, and cost behavior. It is complete and self-sufficient for an agent to decide when and how to invoke it.

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

  Parameters3/5

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

  The schema already provides full coverage for the single 'domain' parameter with an example. The description reinforces 'ANY domain' and 'competitor', adding slight context but no new technical syntax or format details. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states what the tool does: provides estimated organic traffic, keyword count, and top keywords for any domain. It explicitly positions it for sizing up competitors and distinguishes it from gsc_* tools for the user's own site.

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

  Usage Guidelines5/5

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

  Explicit guidance is provided: use it to size up a competitor the user mentions, and prefer gsc_* tools for the user's own site. It also mentions cost implications, which helps the agent decide when to use it.

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

• search_reportsA
  4.5/5.0
  Behavior4/5

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

  The description adds useful behavioral details beyond the annotations: it states that reading is free (aligning with readOnlyHint) and that the tool returns slugs for read_report. It does not contradict the read-only and non-destructive annotations, and provides extra context about the tool's behavior.

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

  Conciseness4/5

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

  The description is compact, delivering usage guidance, parameter explanation, and output purpose in two sentences. It is not overly verbose, but it packs multiple pieces of information into a somewhat long sentence, which slightly reduces conciseness. Still, it remains clear and well-organized.

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

  Completeness4/5

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

  The description sufficiently explains the tool's role within the set of siblings (returns slugs for read_report) and covers the input and output essentials. The absence of an output schema is compensated by mentioning the return value (slugs). It lacks details on edge cases but is complete enough for an agent to use correctly.

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

  Parameters4/5

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

  The 'query' parameter is already well-described in the schema (domain or fragment with examples). The tool description reinforces this by stating 'Searches by domain or name fragment,' which adds clarity without redundancy. Since schema coverage is complete, the baseline is 3, but the extra emphasis justifies a 4.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: searching for existing reports about growth, traffic, or first users. It explicitly labels itself as a discovery step ('Use this FIRST') and specifies that it returns report slugs for subsequent reading, distinguishing it from other tools like 'read_report'.

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

  Usage Guidelines5/5

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

  It gives explicit usage context: 'whenever the user asks how a product, competitor or domain grew, got traffic, or found its first users.' It also indicates that this is a preliminary step before reading a report, and mentions the search input type (domain or name fragment), making when-to-use very clear.

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

• read_reportA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context: 'Free', the content type ('origin story, dated evidence and SEO footprint'), and the locked-field behavior with a pointer to unlock_report. It does not contradict annotations and enriches them, though it doesn't discuss failure modes 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.

  Conciseness5/5

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

  Two sentences, front-loaded with the primary action and key details (source, cost, content, alternative). No redundancy, every sentence contributes value.

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

  Completeness5/5

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

  For a simple 1-parameter tool with no output schema, the description covers purpose, source of the identifier, report contents, cost, and an alternative for locked fields. It is complete for the tool's complexity.

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

  Parameters4/5

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

  Schema coverage is 100% (slug described as 'Report slug'). The description adds meaning by explaining the slug's provenance ('from search_reports or a finished trace'), which helps the agent locate the correct value. This goes beyond the bare schema description.

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

  Purpose5/5

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

  The description clearly states 'Read one growth report by slug' – specific verb (read) + resource (growth report) + identifier (slug). It also distinguishes from siblings by mentioning the slug comes from search_reports or a finished trace, and contrasts with unlock_report (for locked fields).

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

  Usage Guidelines5/5

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

  Explicitly tells when to use: read one report by slug; advises to cite it instead of guessing how a product grew. It also points to an alternative: 'If timeline fields show as locked, unlock_report can open them (that one costs credits).' This provides clear context and exclusions.

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

• site_audit_startA
  4.7/5.0
  Behavior5/5

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

  Annotations only state readOnlyHint=false and destructiveHint=false, but the description adds critical behavioral details: it costs credits (with price shown before charge), is asynchronous, requires confirmation via a request key, and each finding identifies the affected page. These disclosures go well beyond the annotations and cover important operational traits.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary use case ('Run right after deploying'), and packs essential details (findings, cost, async polling) without redundancy. Every sentence earns its place.

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

  Completeness5/5

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

  Given the tool's complexity (async, confirmation, request key), the description covers the initiation flow, cost implications, how to get results (poll with site_audit_get), and what the output contains (page-specific findings). It is complete for an async start tool, and the schema handles parameter specifics.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining that the confirm field is tied to credit cost ('price returned before any charge on the confirmation field') and that the request key is needed for retries to avoid double charging. This goes beyond the schema descriptions, hence a 4.

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

  Purpose5/5

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

  The description clearly states that the tool crawls a site and reports specific issues (broken links, missing titles/descriptions, redirect chains, thin content, schema gaps), naming the page for each finding. This is specific to the 'start audit' action and distinguishes it from sibling tools like site_audit_get (polling) and research tools.

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

  Usage Guidelines4/5

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

  It says 'Run right after deploying' which gives a clear usage context, and mentions the async nature with polling via site_audit_get as an alternative. It also notes credit costs and the confirmation step, but does not explicitly list when not to use it, so it's slightly below a 5.

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

• unlock_reportA
  4.7/5.0
  Behavior5/5

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

  Annotations only say readOnlyHint=false and destructiveHint=false; the description adds critical context that credits are spent, the unlock is permanent and idempotent, and the website's verdict remains unchanged. This goes well beyond annotation coverage and prevents costly agent mistakes.

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

  Conciseness5/5

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

  Four dense sentences front-load the core effect, then cover cost, permission, idempotency, and behavioral context. Every sentence earns its place; there is no fluff or redundant restating of the title.

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

  Completeness5/5

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

  For a single-parameter, cost-incurring mutation with no output schema, the description fully covers preconditions, side effects, pricing source, repeated-call behavior, and role boundaries. Nothing important is missing.

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

  Parameters3/5

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

  The schema already provides complete documentation for the single required slug parameter ('Report slug'), so the baseline is 3. The description references read_report for cost info but does not add meaningfully new details about the slug parameter itself.

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

  Purpose5/5

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

  The description names a specific action ('permanently unlock') and a specific resource ('report's full timeline, evidence and SEO detail'), clearly distinguishing it from read-only tools like read_report. The scope is concrete: it affects a single account and is billing-relevant.

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

  Usage Guidelines5/5

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

  The description explicitly instructs the agent to quote the exact price from read_report's timelineLocked.cost field and call the tool ONLY after the user explicitly agrees to spend. It also clarifies there is no double-charge for already-unlocked reports, which is a clear precondition/exception guide.

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

• start_traceA
  4.9/5.0
  Behavior5/5

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

  Beyond the sparse annotations, the description discloses important behavior: it takes 60-90 seconds, costs credits, rebuilds from multiple sources, and returns cached reports instead under certain conditions. This gives the agent a clear expectation of side effects, time, and cost. There is no contradiction with the annotations.

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

  Conciseness5/5

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

  The description is compact and front-loaded: the first sentence gives the trigger and primary action, the second conveys cost, caching, duration, and next step. No wasted words or redundant restating of the tool name.

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

  Completeness5/5

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

  For a paid, asynchronous operation with no output schema, the description covers all operational expectations: trigger, alternatives, duration, cost, caching, and polling mechanism. It is sufficiently complete for an agent to decide when to invoke and what happens next.

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

  Parameters4/5

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

  Schema coverage is 100%, giving baseline 3, but the description adds useful parameter semantics by linking the cache/freshness tradeoff to when refresh matters (costs credits vs. free cached result). It also clarifies that the primary input is a domain, even though the schema already names it.

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

  Purpose5/5

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

  The description clearly states what the tool does—reconstructs a product's growth story from 12 public sources—and explicitly distinguishes it from search_reports, which serves a different lookup purpose. It also points to get_trace for polling, reinforcing the tool's role within the workflow.

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

  Usage Guidelines5/5

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

  It gives explicit when-to-use guidance: run when search_reports finds nothing or the user wants fresh data. It also explains cost and caching behavior (returning cached report free when fresh) and directs the user to poll with get_trace, defining the surrounding workflow.

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