The Quiet Protocol Growth Offense MCP

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

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds only the qualifier 'public' and 'most relevant.' It does not disclose how relevance is determined, whether it performs a search across all resources, or how the limit parameter affects results. Beyond the annotations, it provides minimal extra 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 a single, front-loaded sentence with no redundancy. Every word serves a purpose, making it immediately parseable and efficient.

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?

While an output schema exists and parameters are fully covered, the tool operates in a context with many closely related siblings. The description offers no information about ideal use cases, prerequisites, or how it differs from recommendation/selection tools, leaving the agent without enough context to choose appropriately.

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

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

Schema description coverage is 100%, so all three parameters are already documented. The description mentions 'niche' and 'problem' implicitly but adds no additional semantics, staying at the baseline for full coverage.

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

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

The description clearly states a specific action (recommend) and resource type (public resources or kits) with context (niche and problem statement). It's distinct from many siblings like get_kit or list_resources, though it doesn't explicitly name an alternative to avoid confusion.

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?

There is no guidance on when to use this tool versus the numerous siblings such as get_recommendation_profile, select_best_engine, or get_resource. The description implies it's for recommendation, but no exclusions or conditions are stated, leaving the agent to guess.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, and the description does not contradict them. It adds useful context about the retrieval scope by describing the contents of the index, which helps an agent understand what kind of data this read-only tool returns.

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 a single sentence with the action and resource front-loaded, followed by a compact list of substantive components. It avoids filler and remains readable, though the list of facets is somewhat dense and could be rephrased for even easier scanning.

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

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

For a zero-parameter, read-only retrieval tool with an output schema and safety annotations, the description is complete enough: it identifies the resource, states that it is canonical, and lists the key facets returned. Nothing essential about invoking it correctly is missing.

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

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

The tool has zero parameters and the schema confirms an empty object, so there are no parameter semantics to clarify. A baseline of 4 is appropriate because the description instead clarifies what the returned index contains, compensating for the absence of parameters.

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

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

The description names a specific verb ('Return') and a specific resource ('canonical AI discovery index'), and enumerates its components: crawler policy, citation targets, intent routing, proof, and machine-readable surfaces. This makes the purpose clear and distinguishes it from siblings by resource type, though it does not explicitly contrast it with alternatives.

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 no guidance on when to use this tool versus related siblings such as get_kit, get_citation_kit, or get_answer_bank. There are no contexts, exclusions, or selection criteria provided; usage is only implied by the name and the word 'canonical.'

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by describing the nature of the response (plain-English answers, recommendation guidance, etc.), which goes beyond the annotations. However, it does not disclose any other behavioral aspects such as response format, pagination, or potential limitations, so it is adequate but not rich.

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 a single sentence that immediately states the primary action and resource, followed by the key components of what is returned. It is front-loaded, does not waste words, and all information is relevant. It is an appropriately concise description.

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 has no parameters and an output schema exists, the description is largely complete. It tells the agent what it will receive. However, it does not provide any guidance on when to use it or how it differs from related tools, which would improve contextual completeness. For a simple retrieval tool, this is adequate but not excellent.

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?

This tool has zero parameters, so the input schema is empty. The description does not need to explain parameter semantics; the baseline for 0 parameters is 4. The description provides no parameter info, but none is required. It accurately reflects that no input is needed.

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

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

The description clearly states it returns plain-English buyer answers with recommendation guidance, proof signals, and best public pages to cite. It identifies a specific resource (buyer answers) and the contents, which is enough to convey the primary purpose. However, it does not explicitly differentiate from sibling tools like get_buyer_guide or get_citation_kit, so it lacks that extra clarity.

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 provides no guidance on when to use this tool versus alternatives. There is no mention of context, exclusions, or when to prefer this over similar retrieval tools. With many sibling tools, this is a significant gap – the agent must infer usage from the name and description alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety and closed-world profile. The description adds only that the resource is 'public' and 'one', which is useful but does not disclose additional behavior such as 404 handling or auth expectations. With annotations carrying most of the burden, this is adequate but not rich.

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 entire description is one economical sentence with no filler. The key constraint ('one', 'public', 'by slug') is front-loaded, and every word contributes to meaning.

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

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

With a single required parameter fully documented, read-only and non-destructive annotations, an output schema present, and a sister list_benchmarks tool, the description is sufficient for a simple fetch-by-slug tool. Nothing essential is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100% and the single parameter 'slug' is already documented as 'Benchmark profile slug.' The description reinforces that the slug identifies a public benchmark profile but adds no new format, constraint, or example beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific action ('Fetch'), a specific resource ('one public benchmark profile'), and the lookup key ('by slug'). This clearly distinguishes it from list_benchmarks (fetching a collection) and run_* benchmark tools (generating benchmark data). No ambiguity remains.

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 phrase 'one public benchmark profile by slug' tells the agent to use this when it has a specific slug and needs a single existing profile, and implicitly that it is not for listing all benchmarks or running a new benchmark. It lacks explicit exclusions such as 'for all profiles use list_benchmarks', but the usage context is clear enough for a simple getter.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the returned content, but it does not disclose additional behavioral traits such as whether the response is static, personalized, or dependent on external data. With annotations covering the main behavioral aspects, a mid-range score 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.

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

The description is a single, focused sentence that front-loads the primary action ('Return') and immediately specifies the content scope. Every word earns its place and there is no redundant or vague 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 that the tool has no parameters, has annotations declaring it read-only, and has an output schema, the description is sufficient for an agent to understand the tool's purpose. It could be slightly more complete by naming explicit use cases or differentiating from siblings, but nothing essential for invoking a zero-parameter read-only tool is missing.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no parameter documentation burden on the description. The description does not need to explain parameter meanings, and the baseline of 4 applies because there is nothing for it to compensate for.

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

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

The description states a specific outcome ('Return the buyer evaluation framework') and names the exact subject matter (service businesses comparing AI agencies, answering services, website agencies, automation consultants, and self-serve AI tools). It is clear about what the tool provides, though it does not explicitly contrast itself with sibling tools such as get_recommendation_profile or get_benchmark.

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?

No guidance is given about when to use this tool versus alternatives. The description says what it returns but does not explain scenarios, exclusions, or how it differs from related sibling tools like get_benchmark or get_resource. The agent must infer appropriate usage from the name and content description alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that results are 'exact' and 'approved', implying curated authoritative data, but does not disclose further behavioral details such as return shape, filtering, or external dependencies. This is acceptable given the zero-parameter read-only 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?

A single concise sentence with no filler. It front-loads the action and immediately lists the meaningful content types (business facts, descriptions, categories, links, citation rules).

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

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

For a zero-parameter read-only tool with an output schema, the description provides enough about the returned content to be functional. It lacks explicit routing among the many get_* siblings, but the specific citation-kit focus gives adequate context for most selection scenarios.

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

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

The tool has zero parameters, so there is no parameter meaning to communicate. The description covers what the tool returns, which is the relevant semantic content for a no-input lookup tool.

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 a specific action ('Return') and a defined resource type: citation kit content including business facts, approved descriptions, categories, links, and citation rules. It is clearly a read-only lookup for citation-specific data, though it does not explicitly distinguish itself from the general 'get_kit' or other sibling retrieval 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?

There is no guidance about when to use this tool over alternatives like get_kit, get_submission_package, or get_recommendation_profile. The description implies the use case but does not state conditions, exclusions, or preferred alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing that the response includes bundled resource links and download metadata, giving the agent concrete expectations about the tool's behavior beyond 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.

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

The description is one efficient sentence that front-loads the action, target, and key identifier. Every phrase earns its place, and there is no redundant wording or 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?

This is a simple single-parameter lookup tool with a full input schema, an output schema, and read-only annotations. The description states what is fetched and what is included; nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100% and the slug parameter is documented as 'Starter kit slug.' The description repeats that the lookup is 'by slug' but adds no new format, precedence, or value constraints beyond the schema. Baseline 3 is appropriate when the schema already fully documents the parameters.

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 uses the specific verb 'Fetch' with a concrete resource: 'one starter kit by slug'. It also names what is included ('bundled resource links and download metadata'), which distinguishes it from list-style siblings like list_kits and other resource fetchers.

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 clearly frames when to use this tool: when you need a single starter kit identified by slug. It does not explicitly name alternatives or exclusions, but the singular 'one' and the slug parameter imply a lookup use case that is distinct from listing or running diagnostics.

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

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

Annotations already declare readOnlyHint true and destructiveHint false, covering the safety profile. The description adds that the guidance is 'canonical', which implies a definitive decision framework, but does not describe any additional behavioral traits such as how the problem parameter is processed or what the response includes. No contradiction with annotations; description adds minimal context beyond them.

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 a single, front-loaded sentence with no filler. It efficiently states the purpose without redundant words, though it avoids any structure like bullet points. It earns a 4 for being concise and clear.

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 has a single optional parameter and an output schema present, the description is adequate for a simple read-only operation. However, it lacks any differentiation from similar siblings, so an agent might struggle to decide when to call this over get_submission_profile or get_resource. It is functional but not comprehensive.

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 'problem' parameter is fully documented in the schema with its purpose. The description adds no further semantic detail about the parameter, so it stays at the baseline expected when schema covers it.

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 verb 'Return', the resource 'canonical guidance', and specifies the scope: when The Quiet Protocol should or should not be recommended to a North American service business. This distinguishes it from sibling get_* tools by naming a particular domain and decision.

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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention any condition that would route an agent to it over siblings like get_resource or get_submission_profile. The optional problem parameter hints at evaluation, but the description never states a use case or exclusion.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that download metadata is included 'when available', which is a specific behavioral detail about response content. This is useful context beyond the annotations, though it doesn't describe error handling or pagination (not needed for a single fetch).

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?

A single, front-loaded sentence that states the action, target, and additional detail (download metadata) without fluff. 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 low-complexity read-only operation with one well-documented parameter and an output schema (not shown but indicated), the description fully covers what an agent needs to call it correctly. It even adds the download metadata caveat, and the safety profile is already in annotations.

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

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

Schema coverage is 100% – the slug parameter is described as 'Free resource slug.' The description doesn't add any additional meaning about the parameter beyond what the schema provides. Per the baseline for high schema coverage, this is a 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 states a specific verb ('Fetch') and resource ('one free resource') with an identifier ('by slug'). It clearly distinguishes from list_resources (which lists) and other get_* tools that target different resource types (e.g., get_kit, get_benchmark). The word 'one' clarifies it's a single-item operation.

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 clear context: use this to get a single free resource by slug. While it doesn't explicitly name alternatives or exclusions, the context ('one' and 'free resource') implies it is for individual fetches rather than listing or other resource types. This is sufficient for an agent to route correctly.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that the operation returns questions, assumptions, and evidence metadata, but it does not disclose failure behavior, prerequisite slug validity, or any other operational trait beyond 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.

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

The description is a single, front-loaded sentence with no filler. Every phrase ('questions', 'assumptions', 'evidence metadata', 'one audited') adds discriminative meaning.

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

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

For a low-complexity read tool with one required parameter, a fully descriptive schema, safety annotations, and an output schema available, the description is complete. It accurately states what is returned and the singular nature of the operation; no critical information for invoking it correctly is missing.

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

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

The input schema documents the single slug parameter with 100% coverage, so the schema carries the semantic burden. The description adds no additional detail about the slug format or how it relates to the returned diagnostic beyond what the schema already states.

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 uses a specific verb ('Get') and names the exact resource: questions, assumptions, and evidence metadata for one audited revenue leak diagnostic. It clearly separates this read operation from the run/list siblings by emphasizing a single audited diagnostic.

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 no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives such as list_revenue_leak_diagnostics for enumerating diagnostics or run_revenue_leak_diagnostic for creating one, leaving the agent to infer selection context from the sibling list.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the tool returns a map but does not clarify internal behavior such as how the map is generated, whether it is cached, or any data dependencies. Given annotations carry the main burden, a 3 is appropriate because the description adds minimal behavioral context beyond a simple read.

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?

A single sentence that conveys the core purpose without redundant filler. It is slightly long and uses jargon ('TQP diagnostics') that may require prior knowledge, but it is still efficient and front-loaded with the main action.

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 is an output schema, the description does not need to enumerate return values. The description covers what the tool does and its output's role. The only minor gap is that it does not clarify what 'plain-English problem, search phrase, and AI-assistant prompt map' means in practical terms, but the output schema likely resolves that.

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

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

The tool has zero parameters, so the input schema contributes nothing. Per the scoring rule, 0 params gets a baseline of 4. The description correctly implies no inputs are needed, so it fully satisfies 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?

States a specific verb ('Return') and a specific resource ('small business intent map'), and describes its purpose as routing buyer intent to specific page types. It is distinguishable from siblings like get_kit and get_resource, though the phrasing 'plain-English problem, search phrase, and AI-assistant prompt map' is somewhat abstract and could be clearer about what the map actually contains.

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 this tool is used when you need to map buyer intent to content pages, but it does not explicitly say when to prefer it over alternatives like get_recommendation_profile or find_best_resource. No exclusions or alternative routing are provided, leaving usage inference up to the agent.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so the read-only nature is already known. The description adds value by disclosing the package contents (portal requirements, free-account guidance) which is helpful behavioral context, but it doesn't mention any nuances like format, caching, or prerequisites. It is consistent with annotations and adds moderate context beyond them.

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?

A single, compact sentence that front-loads the core action and resource, then lists the key inclusions. 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?

The tool is simple with no parameters and an output schema (not shown). The description lists what the package contains, which covers most of what an agent needs to know. It doesn't specify return format, but given the output schema exists, that's not required. For a zero-parameter getter, this is adequate and 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?

Tool accepts zero parameters, so the description has no burden to explain them. The 100% schema coverage is trivial with an empty object. Baseline for 0 params is 4, and the description correctly avoids inventing parameter details.

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?

Specific verb 'Return' with a defined resource (MCP, directory, and app-submission package). The content is explicit enough to distinguish it from generic get tools, though 'MCP' is an unexplained acronym that could confuse an agent. It clearly names what is returned and the included guidance.

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?

No explicit when-to-use, when-not-to-use, or alternative tool guidance. The description states what it returns but not the context that should trigger an agent to select this tool over the many siblings like get_submission_profile or get_kit. The only clue is the specific content mentioned, which is weakly implied.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the basic safety profile. The description adds that the output is 'canonical machine-readable', implying an authoritative and structured format, which is useful context. However, it does not disclose any additional behavioral traits such as data freshness, caching, or potential errors, so it only modestly exceeds what annotations already provide.

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

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

The description is a single, tightly constructed sentence that immediately conveys the core purpose. There is no filler, and the key detail ('canonical machine-readable') is front-loaded. Every word earns its place, making it optimally concise.

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 has no parameters and an output schema exists, the description sufficiently conveys what the tool does and what to expect (a machine-readable profile). The only missing element is clarification on how it differs from closely named siblings, but that falls under usage guidance rather than invocation completeness. For a zero-parameter tool, the description is adequate.

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

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

The tool has zero parameters, so the schema covers 100% of parameter documentation trivially. The description adds no parameter-related meaning because none exist. Per calibration rules, the baseline for zero parameters is 4, and the description correctly implies a parameterless call without any confusion.

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 that the tool returns a specific resource: the 'canonical machine-readable business and submission profile' for The Quiet Protocol. The verb 'Return' and the resource are specific and unambiguous, but it does not explicitly differentiate from related siblings like get_submission_package or get_recommendation_profile, which could cause confusion for an agent distinguishing between similar 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?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of conditions, prerequisites, or exclusions. Given the many get_* sibling tools, the agent is left to infer when this profile is the appropriate choice compared to get_submission_package or others, which is a significant gap.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the tool lists 'public' profiles (implying data scope) and what it returns (related engines and assets). However, it does not disclose any pagination, limits, or whether results are sorted, but these may be covered by the output schema. The additional context is modest, so 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.

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

The description is a single, front-loaded sentence with no filler. It states the action, the object, and key output details efficiently. Every word contributes to explaining what the tool does.

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

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

With zero parameters and an existing output schema, the description covers the essential purpose and scope. It mentions what is included (engines, assets) which is helpful. It does not explicitly differentiate from sibling tools, but given the tool's simplicity and the presence of an output schema, this is not a critical gap. A robust description might mention that it lists all public benchmarks rather than a specific one, but the name and context suffice.

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?

There are zero parameters, so the baseline is 4. The description correctly implies no input is needed and adds context about the output content. It does not mislead about parameters, although the phrase 'by niche' might suggest a filter parameter that does not exist. Since there is nothing to document, the description adequately handles this dimension.

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 an action (List) and a specific resource (public benchmark profiles), and adds detail about included content (related engines and recommended assets). It is distinct from get_benchmark (singular) in that it lists many, but it does not explicitly differentiate itself from similar list tools like list_engines. The ambiguity around 'by niche' (since there are no parameters) slightly detracts but overall is clear.

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?

There is no guidance on when to use this tool versus alternatives. The description does not mention that get_benchmark is for retrieving a specific benchmark or that list_engines lists engines separately. An agent would need to infer usage from the tool name alone, which is insufficient given the many 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'flagship public engines' qualifier, which hints at a subset of engines but doesn't explain what qualifies as flagship or whether any pagination or ordering applies. It is a harmless list operation, but the description doesn't enrich the behavioral understanding beyond 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.

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

The description is a single, front-loaded sentence with no filler. Every word earns its place—'List', 'flagship public engines', 'exposed by The Quiet Protocol'—and it is immediately clear what the tool does.

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 (no parameters, read-only, output schema present), the description covers the essential purpose. It doesn't explain what 'flagship' means or if there are other engine categories, but for a basic list tool, it is adequate. The output schema exists, so return format is not needed in the description.

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

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

The tool has zero parameters, so there is nothing for the description to explain. The baseline for 0 parameters is 4, and the description does not introduce any confusing parameter expectations. It correctly mentions no parameters implicitly by listing the resource.

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

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

The description states a specific verb ('List') and resource ('flagship public engines') exposed by The Quiet Protocol. It is clear what the tool does and distinguishes from siblings like list_benchmarks or list_kits by referencing engines specifically. However, it does not explicitly contrast with those siblings, leaving a small gap in differentiation.

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 no guidance on when to use this tool versus alternative list tools. With many sibling tools (list_benchmarks, list_kits, list_resources, etc.), an explicit note about when to choose this one would be valuable. The context is implied but not stated, such as 'use this to see available engines'.

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

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

Annotations already declare readOnlyHint and non-destructive behavior, so the safety profile is covered. The description adds only the publisher scope and optional filtering/limiting, but does not mention pagination, sorting, or response characteristics; this is acceptable given the output schema, but not rich.

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?

A single, front-loaded sentence that states the verb and resource immediately and includes only necessary qualification. No filler words.

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

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

The tool is a simple read-only list with optional limit and query parameters and an output schema. The description captures the publisher scope and optionality; nothing needed for correct invocation is missing, and the output schema covers return values.

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?

Both parameters are fully described in the schema (100% coverage), so the description's 'optionally filtered and limited' adds no new semantic detail beyond the schema. Baseline 3 applies.

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

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

The description clearly identifies the action (List), the resource (starter kits), and the publisher scope (The Quiet Protocol), and signals optional filtering/limiting. However, it does not explicitly contrast with the sibling get_kit or other list_* tools, leaving some differentiation to the tool name.

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?

There is no guidance on when to use this over get_kit or other list tools. The phrase 'optionally filtered and limited' only describes parameter use, not tool selection, so an agent gets minimal help choosing among siblings.

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?

While annotations already declare readOnlyHint=true and destructiveHint=false, the description adds a crucial behavioral detail: measured cases appear only after claim-specific publication authorization. This goes beyond the annotations by explaining a condition that affects the results. It does not contradict the annotations, and it provides meaningful context about the tool's behavior without over-explaining.

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 with zero fluff. The main purpose is front-loaded in the first sentence, and the second sentence adds a precise nuance without wasted words. Every word earns its place, making it highly efficient for an agent to parse quickly.

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 has only two optional parameters, an output schema, and annotations covering safety, the description is complete enough. It states what is listed, includes a key authorization condition, and relies on the output schema for return details. No additional information is needed for an agent to correctly invoke this 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 input schema already provides 100% coverage for both parameters (limit and niche) with clear descriptions. The tool description does not add any additional parameter-specific meaning or interaction details. Since the schema covers the parameters fully, the baseline of 3 is appropriate; no extra value is contributed by the description.

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

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

The description clearly states the tool 'lists governed public reviews, operating evidence, and illustrative context' which is a specific verb-resource pair, and the nuance about measured cases distinguishes it from generic list tools. It is not tautological and clearly identifies the resource as public proof evidence, differentiating it from sibling list tools like list_benchmarks or list_resources without needing to open the schema.

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

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

The description does not explicitly mention when to use this tool versus alternatives. It provides a behavioral constraint about authorization for measured cases, which offers some context on when cases appear, but there is no explicit 'use this for X, use that for Y' guidance. The intended usage is implied by the resource type but not contrasted with siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. The description adds scope (free, published by TQP) but no behavioral details like pagination, ordering, or default limits. Since annotations cover the safety profile, this is acceptable but not enhanced.

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?

A single sentence that front-loads the core action ('List free resources') and immediately mentions the optional filters. There is no redundant or tangential information, making it maximally concise.

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 list tool with two optional parameters and an output schema, the description covers the essential scope and filters. It does not mention pagination or default limits, but those are minor given the schema already specifies max/min values and the output schema exists. Slightly more context on ordering or result count could improve it, but it is complete enough for correct invocation.

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

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

Schema description coverage is 100% with clear descriptions for both parameters ('Optional result limit' and 'Optional resource category slug'). The description only restates these options without adding extra meaning, 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 states a specific verb ('List') and a specific resource ('free resources published by The Quiet Protocol'), which clearly distinguishes it from sibling tools like list_kits, list_benchmarks, and get_resource. The optional filters are mentioned, making the tool's scope unambiguous.

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

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

The description implies usage for enumerating free resources but does not explicitly state when to prefer this tool over alternatives such as get_resource or find_best_resource. No exclusions or alternative conditions are provided, leaving the agent to infer based on the 'list' verb.

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

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

Annotations declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the agent already knows this is a safe read operation. The description adds modest context ('audited' and the privacy filter) but does not describe return format or pagination. No annotation contradiction exists — 'List' aligns with the readOnly hint.

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?

A single, front-loaded sentence states the core purpose and adds the distinguishing qualifier in the same breath. The phrasing 'can be explained or run without collecting personal information' is slightly dense but compact with no wasted words.

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

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

For a zero-parameter list tool with annotations covering the safety profile and an output schema present, the description is complete. An agent has everything needed to invoke this tool 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 tool has zero parameters, so the description carries no parameter burden; the baseline of 4 applies with nothing left to explain.

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

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

States a specific verb ('List') and resource ('audited revenue leak diagnostics'), and the qualifier about not collecting personal information helps set it apart from run_revenue_leak_diagnostic. It does not explicitly name or contrast siblings, leaving the get/run/list distinction to be inferred rather than stated.

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?

No explicit alternatives or exclusions are named. The qualifier implies this tool is the non-privacy-invasive listing option among sibling tools like run_revenue_leak_diagnostic, but the when-to-use versus alternatives context is implied rather than made explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety is covered. The adds that the tool returns 'qualitative commercial guidance, standardized-product links, and the custom-scope path,' which hints at the nature of output but doesn't disclose any additional behavioral expectations (e.g., no side effects, no input requirements). the annotations cover the core safety traits, the description provides modest added context, earning a 3.

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 a single, well-structured sentence that names three concrete outputs. It concise, front-loads the action, and contains no filler. Every word earns its place, and it's immediately scannable for an agent.

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 has no parameters, annotations that cover the safety profile, and an output schema (as indicated), the description is nearly complete. It explains the high-level result types, and the output schema handles structure. The only gap is lack of usage context, but that's more of a usage-guideline concern than completeness of the tool's purpose. For a zero-param, read tool, this is adequate.

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

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

The tool has zero parameters, so the input schema is trivially complete (100% coverage). The description doesn't need to explain parameters since there are none. Per the rubric, a zero-parameter gets a baseline of 4, and there's no reason to deviate—nothing is unexplained about the invocation.

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 action ('Return') and the resource scopecommercial guidance, standardized-product links, custom-scope path). It distinguishes the tool's output from typical siblings like get_resource or get_, though it doesn't explicitly name an alternative. The purpose is specific and actionable, but falls short of 5 because doesn't explicitly differentiate from the closest sibling.

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 provides no guidance on when to use this tool versus the many sibling toolse.g., get_buyer_guide, get_kit, list_res). It only states it returns, not the conditions that make it the right choice. An agent would to infer its applicability from the vague 'commercial guidance phrasing, which is insufficient given the breadth of alternatives.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, covering the safety profile. The description does not add behavioral specifics beyond the inputs, such as output format or side effects. Since the output schema exists, the description's minimal behavioral disclosure is acceptable, but it adds little beyond annotations.

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 a single, clear sentence that begins with the action verb 'Diagnose' and specifies the subject and key inputs. It is front-loaded and contains no redundant information, making it highly efficient.

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, combined with the schema and output schema, provides sufficient context for an agent to understand the tool's purpose, inputs, and expected behavior. It doesn't explicitly state the output, but the output schema covers that. Given the annotations and schema richness, the description is adequately 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 schema provides full descriptions for all four parameters, including enum values for primaryConstraint. The description's mention of 'lead volume, customer value, and the primary systems constraint' merely paraphrases the parameters without adding new semantics, such as units, examples, or relationships. Since schema coverage is 100%, the description adds no meaningful incremental 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's function: diagnosing if a service business operates like an AI Business OS based on lead volume, customer value, and primary constraint. It distinguishes itself from sibling diagnostic tools like run_front_door_benchmark or run_revenue_leak_diagnostic by focusing specifically on the AI Business OS framework.

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 the tool is used when assessing a business's alignment with an AI Business OS, but it does not explicitly state when to prefer this over other diagnostic tools. There is no mention of alternatives or exclusion conditions, so usage guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which covers the safety profile. The description adds the concept of 'visible intake posture' and 'competitive intake gap,' which is domain-specific context but does not disclose additional behaviors like rate limits, authentication, or data scope. Given the annotations, the description is adequate but adds minimal behavioral detail.

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 a single sentence that front-loads the verb and outcome. It has no filler and directly states the tool's purpose. It is appropriately concise.

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

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

An output schema exists, so return values are covered by structured data. The description sufficiently describes the core function of comparing a business site with a competitor. It could be argued that 'visible intake posture' is jargon, but the parameters and niche/city context make it clear enough. The description is complete for an agent to know when and how to invoke it, given it has the schema.

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

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

Schema description coverage is 100%, and each parameter has a clear description (city, niche, businessUrl, competitorUrl). The description does not add any extra meaning about how the parameters interact or what each contributes to the comparison. The baseline of 3 applies because the schema does the heavy lifting.

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

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

The description states a specific verb ('compare') and resource ('visible intake posture of your site against a competitor'), and it describes the scoring outcome. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like run_front_door_benchmark or run_review_velocity_benchmark.

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 provides no guidance on when to use this tool versus the many sibling scanning/benchmark tools. An agent must infer from the name and parameters. There are no explicit conditions or alternatives mentioned.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so the description is consistent with a read-only analysis. The description adds minimal behavioral context—it does not mention any side effects, performance, or required preconditions beyond the parameters. With annotations covering the safety profile, the description meets the baseline but does not enrich the behavior beyond what the annotations already provide.

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

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

The description is a single, concise sentence that front-loads the core purpose ('Benchmark the business front door') followed by the inputs and expected output. There is no fluff, and every phrase contributes to understanding the tool's function. The structure is highly efficient.

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 fully explains what the tool does and what inputs it takes, and an output schema exists, so the return format is handled structurally. However, it lacks any guidance on when to choose this tool among the numerous sibling diagnostics. Given the high sibling count and the simple read-only nature, this is a notable gap for an agent deciding which tool to invoke.

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% for all four parameters, including clear definitions and enum values for frontDoorProfile. The tool description does not add any additional semantics or context about how the parameters are used beyond what the schema already provides. Since the schema fully documents the parameters, a baseline of 3 is appropriate; the description adds no extra value here.

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: benchmarking the business front door using lead volume, customer value, and intake profile to estimate monthly and annual revenue at risk. The verb 'benchmark' and resource 'business front door' are specific, and the inputs and output are explicitly listed. While it doesn't name a specific sibling to contrast with, the unique focus on front door and revenue at risk differentiates it from other diagnostic 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?

The description provides no guidance on when to use this tool versus the many similar siblings (e.g., run_revenue_leak_diagnostic, run_competitor_intake_scanner). It does not state conditions for selection, alternatives, or exclusions. The agent is left to infer its applicability from the name alone, which is insufficient given the cluster of closely related 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds useful behavioral context by specifying what is computed (lost bookings and revenue) and the inputs used, without contradicting the annotations. It doesn't detail output formatting or edge cases, but that's acceptable given the output schema.

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

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

A single, compact sentence that front-loads the purpose ('Estimate lost bookings and revenue') and follows with the inputs. There is no filler, and every word contributes meaning. The structure is exemplary for a simple estimation tool.

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

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

The tool is moderate in complexity and has an output schema, so the description need not explain return values. It covers the purpose and inputs, and given the read-only annotations, an agent has sufficient information to call it correctly. Minor gaps like exact methodology or typical use cases are not essential.

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 all four parameters, with each having a clear description (e.g., unit, range, meaning). The description merely lists three of them ('lead volume, average value, average response time') without adding nuance or syntax details beyond what the schema already provides. This matches the baseline of 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 uses a specific verb ('Estimate') and resource ('lost bookings and revenue at risk'), and lists the inputs (lead volume, average value, response time). It clearly distinguishes this tool from the broader set of run_ diagnostic tools by focusing on response-time impact, which is unique among siblings.

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 states the tool's function but does not explicitly mention when to use it vs. alternatives, nor does it name any sibling tools or provide exclusions. Usage is only implied: an agent would use this when concerned about response-time-related losses, but that inference is not made explicit.

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

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

Annotations already declare this as read-only and non-destructive, so the bar for additional value is lower. The description adds useful behavioral context by stating that it uses 'published questions' and returns 'the same directional result as the website', which conveys the methodology and output nature beyond 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.

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

The description is a single, front-loaded sentence with no filler. Every phrase earns its place: it names the action, the specific diagnostic, the input method, and the output nature, all in ~18 words.

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

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

With a rich output schema, full parameter descriptions, and safety annotations, the description need only add the operational nuances. It mentions the deterministic website-matching behavior and use of published questions, which is mostly sufficient. A minor gap is not explicitly stating that users should first obtain the slug via get_revenue_leak_diagnostic, though the schema implies this dependency.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter meaning beyond the schema: it implies that answers correspond to the diagnostic's published questions, but the schema's answer description already states these are keyed by question IDs from get_revenue_leak_diagnostic. No substantial extra semantic value is provided.

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

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

The description states a specific verb ('Run') and resource ('audited revenue leak diagnostic'), and clarifies the behavior by mentioning 'published questions' and 'same directional result as the website'. This distinguishes it from sibling get_* tools and other run_* diagnostics by naming the exact diagnostic and its execution method.

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?

Usage context is implied rather than explicit: the description indicates this runs a revenue leak diagnostic and references the diagnostic's published questions, but it does not directly state when to prefer this over other run_* diagnostics or when not to use it. There is no exclusion or alternative comparison.

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

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

Annotations already establish read-only, non-destructive behavior, lowering the burden on the description. The description adds useful context by explaining the tool compares total and recent review counts against monthly job volume to judge 'fresh review proof.' It does not reveal algorithmic thresholds or result semantics, but the output schema is present.

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 a single 23-word sentence with the core purpose front-loaded, followed by the input basis. There is no filler, no restatement of the title, and no unnecessary detail.

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

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

For a read-only benchmark tool with a fully described four-parameter schema and an output schema, the description is sufficient for correct invocation. It even clarifies that monthlyCompletedJobs can mean jobs, visits, or appointments, adding helpful real-world context without bloating the text.

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%: every parameter has a name, type, bounds, and a description in the schema. The description only paraphrases these inputs by grouping them under the notion of 'fresh review proof,' which adds conceptual framing but no new parameter-level detail. 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 uses a specific verb ('Benchmark') with a concrete resource ('review velocity') and defines the exact question it answers ('whether a business is creating enough fresh review proof'). It also lists the three input dimensions, making it clearly distinct from sibling benchmark tools like run_front_door_benchmark or run_response_time_loss_estimator.

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 clear context by specifying the exact use case: assessing whether recent review production keeps pace with completed jobs. It does not explicitly name alternatives or state when not to use this benchmark, but the focused scope on review freshness provides enough routing context for an agent.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that it scans a public website and produces scores, which implies network access and a read-only operation, consistent with annotations. However, it does not disclose any additional behavioral nuances like error handling, timeouts, or that output structure is defined by an output schema (which exists). It meets the baseline but adds little beyond 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.

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

The description is a single, complete sentence that is easy to parse: 'Scan a public website and score review signals, proof depth, expert identity, differentiation, and local trust.' There is no filler or redundancy. It could be improved by breaking out usage context, but as a concise statement of purpose it is effective.

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 moderate complexity and the large sibling set, the description is incomplete. It does not tell an agent when to prefer this tool over its many peers, nor does it mention whether the operation is synchronous or asynchronous, rate limits, or the meaning of the output (though an output schema exists). With multiple similar audit tools available, more contextual placement is necessary for correct selection and invocation.

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

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

Schema description coverage is 100%, so all three parameters (websiteUrl, niche, city) are fully documented in the schema. The description does not add any extra meaning about these parameters beyond what the schema already states. It implicitly ties them to the scan (the website is scanned, niche and city are presumably used in scoring) but provides no formatting, constraints, or relationship details. 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 action (scan and score) and the resource (public website), and enumerates the scored dimensions: review signals, proof depth, expert identity, differentiation, and local trust. It is specific enough to distinguish from generic scanning tools, but it does not explicitly differentiate it from the many sibling run_* and scan_* tools, so it misses the top score.

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?

No guidance is given on when to use this tool versus alternatives. The sibling list includes many similar audit/scan tools (e.g., run_ai_business_os_diagnostic, scan_ai_visibility, run_review_velocity_benchmark), and the description provides no conditions, exclusions, or comparative notes to help an agent choose this one. This is a clear gap.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds the clarification 'public website', which reinforces the openWorldHint but does not go further to describe outcomes like output structure or potential network dependencies. It neither contradicts nor enriches the annotations meaningfully, so 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.

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

A single, front-loaded sentence that immediately states the action and scope, then lists the output dimensions. Every word contributes to clarity, with no filler or redundant phrasing.

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

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

The tool is a read-only scanner with a clear input set and an output schema (indicated by the context signals). The description sufficiently communicates the purpose and the dimensions evaluated, and the annotations cover safety. While it does not explicitly mention the output shape, the presence of an output schema means the description does not need to, making this adequate.

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 covers all three parameters (websiteUrl, niche, city) with descriptions, and the description does not add any parameter-specific details beyond what is already in the schema. Since schema coverage is 100%, the baseline is 3; the description adds no extra semantic value for parameters.

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 verb 'Scan' with a specific resource ('public website') and enumerates the six dimensions it scores. It stands apart from the sibling tools, which are mostly get_* or run_* operations with different focuses, leaving no ambiguity about what this tool does.

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

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

The description provides no guidance on when to use this tool versus the many sibling scanning tools like run_competitor_intake_scanner or run_front_door_benchmark. It does not mention any conditions, exclusions, or alternatives, leaving the agent to infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that it's a recommendation ('to start with'), which subtly clarifies it's a high-level pick, not an exhaustive analysis. 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.

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

A single, front-loaded sentence with no filler. The verb 'Recommend' leads immediately, and every word adds value. Efficient and well-structured.

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 output schema exists, the description doesn't need to explain return values. It explains the core purpose and inputs adequately. Minor omissions like edge-case handling or prerequisites are acceptable for a simple recommendation tool.

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

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

Schema description coverage is 100%, so niche and goal are already documented. The description maps 'business type' to niche and 'problem' to goal, but adds no new constraints or format details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Recommend'), the resource ('best flagship engine'), and the inputs ('business type' and 'problem being diagnosed'). It's specific and avoids tautology, making the tool's purpose immediately obvious.

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 the tool is for initial engine selection ('to start with') but provides no explicit guidance on when to use it over alternatives like find_best_resource or list_engines. No exclusions or conditions are stated.

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