tracetify-mcp

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

No annotations are provided, and the description fully carries the behavioral burden. It discloses that links are hand-verified, dead/nofollow entries removed, and the per-account daily credit behavior with free repeat calls, which is critical operational context.

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 compact sentences, each providing essential info: list quality, usage context, and cost model. No redundant or filler text; all sentences earn their place.

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

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

Given the tool's low complexity (no params, no output schema), the description is fully complete. It covers purpose, usage, data quality, and cost behavior, making it self-sufficient for an agent to decide and 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?

The input schema has zero parameters (100% coverage vacuous). The description adds meaningful semantic information by explaining client-side filtering by language/type/pricing, which tells the agent about the data's structure beyond the empty schema.

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

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

The description clearly states the tool provides 'a hand-verified list of directories and launch platforms that actually give links,' with specific quality criteria. This distinguishes it from sibling research tools (e.g., research_backlinks) as a launch/backlink directory resource.

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 'Use when the user wants backlinks or launch exposure for a new product,' giving clear context. It also tells the agent to 'filter client-side by language/type/pricing,' but does not mention when not to use or name alternative sibling tools.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool is free, that it polls for a status, and that it returns a 'done' status. It doesn't elaborate on other fields or potential side effects, but for a simple polling tool this is sufficient.

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 extremely concise—two sentences covering purpose, usage guidance, and polling advice. It's front-loaded with the purpose and contains zero filler. Every word earns its place.

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

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

For a single-parameter polling tool with no output schema, the description covers all essentials: what it does, when to use it, how often to poll, and what to do next. It's fully sufficient for an agent to utilize 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% for job_id, which is described in the schema. The description adds critical context by specifying that job_id comes from start_trace, linking the tools together. This exceeds the baseline 3 by providing provenance for the parameter.

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 clearly states the action ('Poll') and resource ('a trace started with start_trace'), and distinguishes from siblings by referencing start_trace and read_report. It's specific and unambiguous.

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

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

Provides explicit guidance: polling interval (10-15s), not a tight loop, and when to transition to read_report when status is 'done'. This tells the agent exactly when and how to use this tool vs 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?

No annotations are provided, so the description carries the full burden. It adds useful behavior: 'this tool tells you if it is not [connected]' and mentions it's free. However, it does not explicitly state whether the operation is read-only, nor does it disclose any side effects, rate limits, or data handling. This is a moderate gap.

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 pack a great deal of information: purpose, timing, unique value, prerequisites, and a behavioral note. Every word earns its place; there is no fluff or repetition.

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 tool with one optional parameter and no output schema, the description covers the key aspects: what data it returns, when to use it, and the GSC connection prerequisite. It could mention output structure or read-only nature, but the provided metrics list and error-checking behavior make it reasonably complete.

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

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

The only parameter, range_days, is fully covered by the schema with description '28 (default) or 90'. The tool description does not mention the parameter, but the schema already provides clear semantics, so the description adds no extra value. Baseline of 3 is appropriate.

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

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

The description clearly states the tool provides clicks/impressions trend, device split, and period comparison from the user's connected Google Search Console. It distinguishes from siblings like gsc_pages and gsc_queries by framing this as the high-level overview to use first, with 'numbers no other tool has'.

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 'Use this before touching SEO on the user's own site', giving a clear timing/context for use. It also notes the prerequisite that GSC must be connected, but does not explicitly name alternative tools for other use cases.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool is free and uses the user's own connected Search Console data, which adds context. However, it does not explicitly state that the tool is read-only or mention any potential side effects. For a data retrieval tool, this is likely fine, but the description could be more explicit about its non-mutating nature.

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 two concise sentences that are front-loaded with the primary purpose. It avoids unnecessary detail and directly states what the tool does, its notable feature (high-impression low-CTR pages), and a hint at how to act on the data. Every sentence earns its place.

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

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

For a simple tool with one optional parameter and no output schema, the description is fairly complete. It explains the core output (pages ranked by performance) and provides an actionable insight (underselling titles/descriptions). While it does not detail exact metrics or fields returned, the context given is sufficient for most use cases. The lack of explicit output description is a minor gap, but not critical given the tool's simplicity.

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

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

The schema already has 100% coverage for the single parameter (range_days: '28 (default) or 90'), so the description does not need to add much. The description does not mention the parameter at all, but since coverage is high, it does not need to compensate. The score is baseline 3.

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

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

The description clearly states the tool's function: returning the user's pages ranked by search performance, with a specific focus on high-impression low-CTR pages that are underselling. This distinguishes it from siblings like gsc_queries (which focuses on queries) and gsc_overview (which likely provides a summary). The verb 'ranked' and resource 'pages' are specific and unambiguous.

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

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

The description implies usage for page-level performance analysis, especially for identifying pages with poor CTR that could be improved. However, it does not explicitly contrast with sibling tools (e.g., when to use gsc_pages vs gsc_queries) or state exclusions. The mention of 'fix those files right in this editor' hints at an actionable use case, but this is not a formal usage guideline.

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?

No annotations are provided, so the description carries the burden. It discloses that the data is from the user's connected Search Console, is free, and represents real ranking keywords. It doesn't mention any side effects or limitations (e.g., data freshness, sampling), but for a read-only reporting tool, this is adequate. The description adds value beyond the schema by explaining the data source and use case.

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 concise and front-loaded with the core purpose. It uses two sentences to convey purpose, use cases, and data source without any fluff. Every sentence earns its place.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is complete enough. It explains what the tool does, when to use it, and what data it returns. It could mention the output format, but since there's no output schema, the description's mention of 'position, clicks and CTR' gives a good sense of the return values. The sibling tools are distinct, and the description helps differentiate.

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

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

The schema description coverage is 100% (the only parameter, range_days, is described as '28 (default) or 90'). The description doesn't add much beyond that, but it's not needed since the schema already covers it. The baseline for high coverage is 3, and the description doesn't introduce any new parameter semantics.

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 clearly states the tool provides the user's real ranking keywords with position, clicks, and CTR, and distinguishes it from siblings by focusing on queries. It also gives concrete use cases (deciding what to write, which page to improve, verifying page movement after edits).

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

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

The description explicitly explains when to use this tool (when deciding what to write or which page to improve, e.g., finding queries at position 5-20) and even mentions how to use it after editing a page to verify movement. It also notes it's free and uses the user's own connected Search Console data, which helps set expectations.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool is free, what content the report contains (origin story, dated evidence, SEO footprint), and the conditional locked-field behavior. It does not mention auth or rate limits, but for a simple read tool this is strong disclosure.

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 concise sentences, front-loaded with the core action and resource, then adding cost, content, and alternative-tool guidance. Every sentence earns its place with no redundancy.

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 read tool with no output schema, the description is complete: it explains what the report contains, how to obtain the slug, cost implications, and the related unlock behavior. No critical context 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 schema already fully documents the single 'slug' parameter, so baseline is 3. The description adds meaning by specifying where valid slugs come from (search_reports or a finished trace), which helps the agent supply a correct value.

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 clearly states the tool reads one growth report by slug, naming the exact resource and action. It also distinguishes itself from siblings like search_reports (finding reports) and unlock_report (opening locked timeline fields).

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

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

It explicitly says to use slugs from search_reports or a finished trace, advises citing the report instead of guessing, and directs users to unlock_report when timeline fields are locked. This provides clear when-to-use and alternative 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?

With no annotations, the description carries the transparency burden. It usefully discloses that the tool costs credits and that cached results are free, which is important operational context. However, it does not describe output format, pagination, rate limits, or any other behavioral details, leaving a meaningful gap.

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 three concise sentences, each serving a purpose: defining the output, stating when to use it, and noting cost/companion tool. No filler or redundancy.

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 is simple (one parameter, no nested objects) and there is no output schema, the description provides enough orientation for an agent: what it returns, when to use it, and cost implications. It could be more complete by describing the response format or clarifying domain inputs, but it is not inadequate.

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 only parameter, domain, has 100% schema description coverage ('Domain to inspect'). The description adds no material parameter-level detail beyond what the schema already states, 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.

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

The description clearly states what the tool does: it identifies who links to a domain and what data is returned (referring domains, authority, anchor texts). It also distinguishes this from the sibling backlink_directories by focusing on the backlink profile rather than places to get listed.

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 use cases ('Use when planning link building or judging how defensible a competitor's ranking is') and recommends pairing with backlink_directories. It does not provide an explicit 'when not to use' scenario, so it falls slightly short of a perfect 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?

With no annotations, the description must carry the behavioral burden. It discloses the cost model (credits vs. free cache) and the nature of the output (platforms, counts, entities). It implies a read-only lookup but does not explicitly confirm it, which is a minor omission given the query-like nature.

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 concise sentences deliver the core function, a usage trigger, and a cost/caching note without any unnecessary words. The information is front-loaded, with the main purpose first and operational details following.

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 one-parameter tool with no output schema, the description covers the essential aspects: what it does, when to use it, and cost behavior. It lacks explicit response formatting or error handling, but those are not critical for this level of simplicity. The cost note is a useful addition.

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 single 'brand' parameter is already fully described in the schema as 'Brand or domain'. The description adds context by framing it as the subject of AI citation lookup but provides no additional format or usage details. Given 100% schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the tool reports how AI assistants like ChatGPT and Perplexity cite a brand, including platforms, mention counts, and associated entities. This distinct purpose immediately differentiates it from sibling tools such as research_backlinks and research_domain_overview.

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

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

The description explicitly directs use when the user asks 'does AI recommend us/them?', which is a concrete trigger. It also mentions the credit cost and free cached results, giving practical guidance. However, it doesn't explicitly list alternatives or when not to use, though the use case is sufficiently narrow.

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

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

With no annotations provided, the description carries the transparency burden. It discloses that the tool costs credits, that cached results are free, and that repeated queries within a week hit the cache. It also signals that the data is estimated, though it does not mention rate limits or output formatting.

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 concise sentences each add distinct value: output and use case, cost/cache behavior, and an alternative tool recommendation. The description is front-loaded and contains no 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 there are no annotations and no output schema, the description still conveys what the tool returns, when to use it, its cost/caching characteristics, and which alternative tools to prefer. For a single-parameter tool, this is sufficient and well-rounded context.

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

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

The schema already documents the single domain parameter with an example, so schema coverage is 100%. The description adds 'ANY domain' and the competitor use case, but no additional formatting or validation details are provided, so the parameter meaning is adequate but not materially enhanced 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 clearly states the tool returns estimated organic traffic, keyword count, and top keywords for any domain, and it explicitly mentions sizing up a competitor. This distinguishes it from the gsc_* sibling tools, which focus on the user's own site data.

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 says when to use the tool ('use to size up a competitor the user mentions'), and explicitly directs users away from it for their own site in favor of gsc_* tools. It also clarifies cost/cache behavior, giving the agent actionable selection 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?

No annotations are provided, so the description carries the full burden. It states the tool 'Returns matching report slugs' and mentions 'reading it is free,' which hints at read-only behavior and low cost, but it does not explicitly declare no side effects, permissions needed, or rate limits. This is adequate but leaves some behavioral aspects implicit.

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 two sentences, front-loaded with the most important usage guidance ('Use this FIRST'), and includes all necessary information without redundancy. Every sentence adds value: the first gives usage context, the second defines the output and search parameter.

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 simplicity (one parameter, no output schema, no nested objects), the description fully covers the purpose, when to use it, and what it returns. It also clarifies the relationship with read_report. No additional behavioral details are essential for this 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?

The only parameter, 'query', is fully documented in the schema with 'Domain or fragment, e.g. "weshop" or "weshop.ai"'. The description's 'Searches by domain or name fragment' adds no new meaning beyond the schema. With 100% schema coverage, the description is not required to compensate, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool searches for growth reports by domain or name fragment and returns matching report slugs for read_report. It uses a specific verb-resource pair ('search reports') and explicitly distinguishes itself from the sibling read_report by describing its output as slugs for that tool.

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 instructs to 'Use this FIRST whenever the user asks how a product, competitor or domain grew, got traffic, or found its first users.' It also notes that 'a report may already exist and reading it is free,' providing clear when-to-use context and a cost benefit. This differentiates it from read_report and other research tools.

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

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

With no annotations, the description carries the transparency burden. It notes 'free to read' indicating no side effects, and mentions 'When finished' which implies polling behavior. It does not detail error handling or blocking behavior, but enough is conveyed for a read-only 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 succinct, consisting of two sentences that convey the essential information without redundancy. It is well-structured and easy to parse.

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 lack of an output schema, the description adequately explains the return value (issue list grouped by severity with affected URLs) and ties it to the overall audit workflow. It could elaborate on the exact structure but is sufficient for typical use.

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 single parameter audit_id is described as 'Audit id from site_audit_start', which adds context beyond a generic string by linking it to the start action. This is useful and covers the schema fully.

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 clearly states the tool's purpose: to poll and retrieve an audit started with site_audit_start, returning the issue list grouped by severity with affected URLs. It uses specific verbs like 'Poll' and 'returns', and distinguishes itself from the start tool by referencing the workflow.

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

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

The description explicitly indicates when to use this tool (after starting an audit with site_audit_start) and provides workflow guidance ('work through it top-down and re-run after fixes'). It implies this is the retrieval counterpart to the start action, offering clear contextual usage.

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

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

With no annotations, the description discloses credit costs, that pricing is returned before charge, and that the operation is asynchronous. These are meaningful behavioral traits that help the agent manage expectations, though it could elaborate more on the confirmation flow.

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: the first is action-oriented and front-loaded with the purpose, the second covers cost and async behavior. Every word earns its place, no redundancy.

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 description covers when to run, what issues are reported, async flow, and cost. It doesn't explain the two-step confirm/request_key mechanism in detail, but the schema handles that, and the polling reference implies the workflow.

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 descriptions cover all three parameters (100% coverage), so the description doesn't need to reintroduce them. It adds some context for confirm (credit cost approval) and the async flow, but not significantly 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 explicitly states it runs after deploying and crawls the site to report broken links, missing titles/descriptions, redirect chains, thin content, and schema gaps. This clearly distinguishes it from site_audit_get (polling) and other sibling tools.

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

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

It gives a clear trigger ('Run right after deploying') and directs the agent to poll with site_audit_get, providing a complementary alternative. It doesn't explicitly state when not to use other tools, but the context is clear.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool rebuilds from 12 public sources, takes 60-90s, costs credits, and may return a cached report for free. It also mentions polling with get_trace. This is strong behavioral disclosure, though it doesn't detail what happens to the trace data or any side effects beyond cost.

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 concise and front-loaded. It starts with the trigger condition, then explains the action, cost, and fallback behavior, and ends with a clear next step. Every sentence adds value, and it's only a few lines 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?

Given the tool's complexity (long-running, cost, caching), the description covers the key aspects: when to use, cost, duration, caching, and polling. It doesn't have an output schema, but it mentions 'Poll with get_trace' which implies the result is asynchronous. It could mention what the output looks like, but the sibling get_trace likely handles that. Overall, it's quite complete for a tool with this complexity.

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 parameters (url and refresh). The description adds context about the url ('Domain to trace') and refresh ('Force a fresh run'), but doesn't add much beyond the schema. The description's mention of 'cached report' and 'fresh data' implicitly relates to the refresh parameter, but the schema already covers it. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Run this when search_reports finds nothing (or the user wants fresh data) for "how did X grow?".' It specifies the verb (run/rebuilds), the resource (growth story from 12 public sources), and distinguishes it from siblings by referencing search_reports and get_trace.

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

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

The description explicitly states when to use this tool ('when search_reports finds nothing (or the user wants fresh data)'), and provides alternatives ('returns an existing cached report free instead when one is fresh', 'Poll with get_trace'). It also mentions cost implications ('Costs credits from the Tracetify balance'), which is crucial for decision-making.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the action is permanent, costs credits, is idempotent ('never charges twice'), and that the verdict remains unchanged ('The verdict stays on the website'). This is rich, honest behavioral context.

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 four sentences, each earning its place: purpose, cost/consent requirement, idempotency, and analyst role. It is front-loaded with the primary action and contains no filler or repetition.

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 description covers the critical operational context: cost, consent, idempotency, permanence, and relationship to read_report. It does not describe the response/return value, but for a one-parameter mutation tool with no output schema, the essential decision-making and invocation context is well covered. A small gap remains around post-unlock behavior, hence 4 rather than 5.

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% for the single 'slug' parameter, so the schema already documents it. The description adds context by tying the slug to a report from read_report and mentioning the timelineLocked.cost field, but it does not add significant new parameter-level meaning. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Permanently unlock a report's full timeline, evidence and SEO detail for this account.' This is a specific verb+resource+scope statement that distinguishes it from siblings like read_report, which reads reports, and search_reports, which finds them.

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

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

The description gives explicit when-to-use guidance: quote the exact price first and call 'ONLY after they explicitly agree to spend.' It also references read_report as the source for the cost field, providing a clear prerequisite and workflow context. This is strong usage guidance.

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