gateway

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the description carries a lighter burden but still adds substantial context: the analysis is static markup only, the detection list is fixed, and crucially it defines the meaning of a clean result — 'no known markup-level issue found,' not full compliance. This directly prevents the common misuse of treating a passing scan as a WCAG compliance certification.

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

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

Two sentences with zero waste. The first sentence front-loads the purpose and complete detection list; the second delivers the limitation and result interpretation. The enumerated failure list is long but earns its place because it tells the agent exactly what checks will run, which is actionable selection information.

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

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

For a one-parameter, read-only scanner, the description covers the key operational context: what it checks, what it can't check, and how to interpret results. The only gap is that no output format is described and no output schema exists, leaving the exact return structure (e.g., pass/fail vs. detailed findings) to inference. The enumerated check list and clean-result semantics cover most of what an agent needs.

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 still contributes meaning beyond the schema's 'full http:// or https:// URL' by constraining that URL to be 'live' and 'publicly reachable', which narrows what URLs are valid inputs. This is genuine added value but modest in extent.

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 ('Scan'), a tightly scoped resource ('a single live, publicly reachable web page's markup'), and enumerates the exact failure classes it targets (missing alt text, unlabeled form fields, missing lang attribute, empty links, skipped heading levels, missing page title, no h1, no skip link). The 'single page' and 'static markup analysis' qualifiers distinguish it from broader siblings like site-audit__audit_site_accessibility_and_agent_safety.

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 communicates when to use the tool by stating the page must be live and publicly reachable, and explicitly says what it cannot do ('can't check color contrast, keyboard navigation, or screen reader behavior'), which functions as a when-not-to-use signal. However, it never names an explicit alternative tool for those broader checks, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about the product nature but does not disclose additional behavioral traits such as rate limits, authentication, or response structure. For a simple zero-parameter read tool, this is acceptable but not exceptional – it adds modest value 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 two sentences with no redundant words. The primary action and product definition are front-loaded, and the usage context is added in the second sentence. Every sentence earns its place.

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

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

For a zero-parameter tool with no output schema, the description fully covers what the agent needs: what the tool returns (pricing and details), what the product is, and when to use it. There is no missing information that would impede 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?

There are zero parameters, so the schema is trivially 100% covered. Per the baseline for 0 params, the score is 4. The description does not need to explain any parameters, and it correctly focuses on the tool's purpose instead.

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: 'Get pricing and details for AdvisorLetter' – a specific verb and resource. It also explains what AdvisorLetter is, which distinguishes it from other info tools like apidrift__get_apidrift_info. The purpose is unambiguous and well-scoped.

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 includes explicit usage context: 'Useful for an agent helping a financial advisor or RIA find a done-for-them... product.' This tells an agent when to use the tool, though it does not explicitly mention alternatives like the sibling advisor-letter__get_sample_issue or state when not to use it. Still, the guidance is clear and actionable.

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 a read-only, non-destructive call. The description adds meaningful behavioral context: access requires no key, it is free, it returns a fixed sample rather than the current issue, and the artifact is an advisor-ready market commentary. 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?

The description is two sentences with the core purpose front-loaded. Every clause adds value: the artifact's nature, the fixed-sample distinction, the paid-subscription contrast, and the free/no-key guarantee. 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?

For a zero-parameter read-only tool with no output schema, the description fully covers what the agent receives, what it is not, and the access constraints. An agent can confidently select and invoke this tool without needing additional documentation.

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 schema coverage is 100%, so there are no parameter semantics for the description to add. The baseline of 4 applies, and the 'no key' note reinforces that no inputs or credentials are required.

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 a specific resource ('sample AdvisorLetter issue'), then clarifies what that resource is: a ready-to-forward weekly market-commentary draft. It also distinguishes the sample from the paid live Monday issue, which prevents confusion with the sibling info tool.

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

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

The description clearly conveys when to use it: when an agent needs a real sample of the AdvisorLetter draft. It also states an exclusion ('fixed sample issue, not this week's live draft') and notes that the live issue is a paid subscription, which helps prevent misuse. It does not explicitly name sibling alternatives like get_advisor_letter_info, but the context is sufficient.

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 context beyond that: it mentions the tool returns a free preview, requires no API key, and personalizes with business name. It does not contradict annotations and adds useful behavioral context about being free and returning a ready-to-use disclosure.

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

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

The description is compact and front-loaded with the primary purpose. Each sentence adds value: it explains what it checks, what it returns, and the free/no-key condition. 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?

With no output schema, the description adequately explains the return values (obligation, placement, disclosure sentence). It also covers the touchpoint categories and the personalization option. It does not detail the exact output structure, but for a read-only check tool this is sufficient. The context signals show no nested objects or output schema, so the description fills the gap well.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds minimal extra semantics—it reinforces that businessName personalizes the output but does not provide syntax or format details beyond the schema. 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 ('check'), a specific resource (Article 50 transparency rule for AI touchpoints), and enumerates the touchpoint categories it covers. It also distinguishes itself from the sibling info tool (ai-disclosure-kit__get_ai_disclosure_kit_info) by focusing on a concrete compliance check rather than general kit information.

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 tells when to use the tool (when you need to check Article 50 applicability and get a sample notice for a touchpoint). It does not explicitly name alternatives or state when not to use it, but the purpose is specific enough that an agent would infer the correct context from the 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 covered. The description adds product detail but no additional behavioral traits such as authentication needs or rate limits; it neither contradicts nor significantly expands on the annotation-provided behavior.

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

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

The description is about three sentences and front-loads the core purpose ('Get pricing and details'). Every sentence contributes relevant information, though the component list is somewhat dense and could be slightly streamlined.

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, parameterless info tool with no output schema, the description gives enough context about what the tool returns and when it is relevant. It does not over-explain, and the absence of an output schema is compensated by the enumerated contents and use case.

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 schema description coverage is 100%, so there is nothing for the description to clarify at the parameter level. Per the baseline for parameterless tools, a score of 4 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 identifies the tool as 'Get pricing and details for AI Disclosure Kit' and enumerates the kit's components and use case. It is easily distinguished from sibling tools like check_article50_disclosure by focusing on product information rather than compliance checking.

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 clear context for when to use the tool: 'Useful for an agent implementing EU AI Act transparency disclosures for its user's product.' It does not explicitly exclude cases or name alternatives, but the context is specific enough to guide selection.

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 mark the tool as read-only and non-destructive. The description adds value by disclosing that it automatically looks up data from SEC EDGAR + market data and that it returns both the score and the risk zone. It does not cover failure modes or rate limits, but the annotations lower the burden.

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

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

Two sentences with no filler. The purpose, version qualifier, input requirement, data sources, and output interpretation are all front-loaded and each clause 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 one-parameter read-only calculator, the description covers the input, data sources, output score, and zone thresholds. The only minor omission is behavior for invalid or unsupported tickers, which is not critical given the schema and annotations.

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

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

Schema description coverage is 100% and the only parameter 'ticker' is already documented in the schema with a US-listed example. The description reinforces that only a ticker is needed, but it adds no meaningful format or constraint information beyond the schema.

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

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

The description opens with a specific verb ('Compute'), names the exact metric, qualifies the version ('public-company, non-financial-services'), and identifies the input as a US-listed ticker. It clearly distinguishes this tool from sibling calculators like compute_dcf or compute_graham_number by defining the focused purpose.

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 when to use the tool: for a 'quick bankruptcy-risk / financial-distress screen' of a US-listed non-financial ticker. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for an agent to recognize the intended use.

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 aligns with this by describing a read-only information retrieval action. It adds value by specifying the content scope (providers, alert types like deprecations, schema changes, pricing shifts), which goes beyond the bare readOnly flag.

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: the first is front-loaded with the core action and resource, and the second adds relevant context about the target audience and value proposition. It is not overly verbose, though the second sentence is somewhat long and could be tightened without losing meaning.

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

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

For a zero-parameter informational tool with no output schema, the description fully explains what the tool returns (pricing, details, alert types, providers) and why it is useful. Nothing critical is missing for an agent to decide whether to call it.

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, and schema description coverage is 100% (trivially, since there are no properties). The description does not need to explain any parameter semantics, and the baseline for a no-parameter tool is 4.

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 'Get' and the resource 'pricing and details for APIDrift', and enumerates the specific providers covered. It distinguishes itself from the sibling 'get_recent_breaking_changes' by focusing on pricing and service details rather than recent changes, though it does not explicitly name that alternative.

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

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

It provides a concrete use case ('helping an engineering team that depends on LLM provider APIs avoid getting blindsided by an upstream breaking change'), which implies when it would be relevant. It does not explicitly state when not to use it or mention sibling tools, but the context is clear enough for a zero-parameter informational tool.

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 adds useful context beyond those: it is free, requires no key, and returns illustrative sample entries rather than a live feed. This is meaningful behavioral context, though it does not describe output shape or rate limits.

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

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

The core behavior is front-loaded in one dense, information-rich first sentence, followed by two brief clarifying statements. There is no filler or redundant wording.

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 sample tool, the description provides enough context: what the entries contain, which providers are covered, that it is illustrative, and that it is free with no key. It gives a hint of return content ('what actually broke and what to check'), but exact response fields are not specified.

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 schema description coverage is 100%, so the baseline for this dimension is 4. The description does not need to explain parameters and introduces none.

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 ('Get') and a concrete resource ('real, dated example entries of the kind of LLM-provider breaking change APIDrift catches'), enumerating providers and change types. The description also distinguishes itself from the paid product by noting it is sample data, not a live feed.

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?

Clearly identifies what the tool returns and contrasts it with the paid subscription (weekly digest plus urgent alerts), letting an agent know when sample entries are appropriate. It does not explicitly name an alternative sibling such as get_apidrift_info, so exclusion 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, so the safety profile is covered. The description adds context about the dataset's source and composition, but doesn't disclose any additional behavioral traits like authentication or rate limits, which is acceptable for a simple info tool.

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

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

The description is concise and front-loaded: the first sentence states the core purpose, and the second adds valuable context about the dataset. Every sentence earns its place with no redundancy.

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

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

For a parameterless tool with no output schema and annotations covering safety, the description is complete. It tells the agent what the tool does, what the dataset contains, and why it's useful, leaving no critical gaps for 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?

With zero parameters, the baseline is 4. The description needs no parameter explanation, and the schema is trivially complete.

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 ('Get details and pricing') and the resource ('US Bank Regulatory Stress Dataset'), and elaborates on the dataset's contents. It distinguishes from the sibling lookup_bank_stress_metrics by focusing on dataset-level info rather than per-bank metrics.

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 a clear use case: for agents building bank-screening or credit-risk models that need a raw data input. It implicitly contrasts with the sibling tool by framing this as obtaining dataset details/pricing rather than querying metrics, though it doesn't explicitly name the alternative.

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

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

Annotations already mark the tool as read-only and non-destructive, and the description adds value by noting it is free with no API key, that figures are citable from official FFIEC filings, and that coverage spans all 4,296 institutions. It does not disclose behavior for not-found banks, but given the read-only hint this is a minor gap.

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

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

The description is front-loaded with the core action and resource, then flows logically through metrics, coverage, usage guidance, and constraints. Every sentence carries distinct information; it is slightly verbose but not padded.

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 only one parameter, no output schema, and annotations covering safety, the description fully covers what the tool does, what it returns, when to use it, and operational details (free, no key, single institution). Nothing critical 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?

The single parameter 'name' is fully documented in the schema (coverage 100%), including examples and minimum length. The description reinforces the 'one institution per call' constraint but does not add new semantic detail beyond the schema, so it meets the baseline without exceeding 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 opens with a specific verb and resource ('Look up one US bank's balance-sheet stress metrics') and enumerates the exact metrics returned (AOCI burden, uninsured deposit ratio, non-performing loan ratio, total assets, state). It clearly distinguishes from the sibling 'get_bank_stress_dataset_info' by focusing on per-bank lookup rather than dataset metadata.

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

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

Provides explicit when-to-use guidance ('Use this when an agent needs a grounded answer to "how stressed is this bank?"') and states a constraint ('One institution per call'). It does not name an alternative tool for exclusion, but the context is clear enough for an agent to decide when to invoke it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful behavioral context: it returns a checklist and a preview, covers specific Visa/Mastercard reason codes, and explicitly notes it is not legal advice. It also clarifies the full letter is a separate paid product, which prevents the agent from promising more than the tool delivers.

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 paragraph that front-loads the core function, then lists covered reason codes, then clarifies the paid product boundary and legal disclaimer. It is reasonably concise, though the reason-code enumeration adds length. Every sentence earns its place, and the structure is logical.

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 checklist tool with 100% schema coverage and no output schema, the description is complete enough: it states inputs, outputs, coverage, and limitations. It could mention that the output is a preview rather than a full letter, but it already does. The only minor gap is not describing the exact format of the checklist or preview, but that is not essential for an agent to invoke the 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?

Schema description coverage is 100%, so the schema already documents all 7 parameters. The description adds context about what the category parameter maps to (Visa/Mastercard reason codes) and what the output will use (tracking numbers, prior-order signals, refund records), but it does not add much beyond the schema's own detailed enum descriptions. 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 verb ('return the evidence checklist') and resource ('chargeback/dispute reason code category'), and explicitly lists the covered reason codes and categories. It clearly distinguishes itself from the separate $39 product that produces the full formatted letter, so an agent can tell what this tool does and does not do.

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 when to use this tool: when a chargeback/dispute reason code category and order details are available, and the user needs the evidence checklist and a preview of the response letter. It also explicitly says the full formatted letter is a separate paid product, which is a useful exclusion. It does not explicitly name sibling tools or state when not to use it, but the context is clear enough.

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

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

The description adds meaningful behavioral context beyond the readOnly/openWorld/destructive annotations: it reveals the tool makes an external fetch, details the scan categories, and explicitly cautions that a clean result is not a full content-safety guarantee. This is precisely the kind of transparency agents need for a web-scanning tool.

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

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

The description is dense but every clause earns its place: it defines the threat categories, gives the invocation trigger, and sets expectations for the result. The structure front-loads the core action before the caveat.

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

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

For a one-parameter, read-only, no-output-schema tool the description is largely complete: it covers what is scanned, when to call it, and how to interpret a clean result. It does not specify the exact return shape (e.g., boolean vs. list of findings), but the interpretation caveat compensates for most of that gap.

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

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

The single parameter is fully documented in the schema (URL, required, format described). The description adds no new parameter-level semantics, but with 100% schema coverage the baseline of 3 is appropriate.

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

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

The description clearly states the tool fetches a URL and scans for agent-hijacking content, then enumerates specific pattern categories. The purpose is concrete and distinct from the general site-audit sibling tool.

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

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

It gives an explicit trigger condition: 'Call this before an autonomous browsing or checkout flow acts on instructions found on a page.' It lacks an explicit when-not-to-use or comparison to site-audit__audit_site_accessibility_and_agent_safety, so it stops short of a full 5.

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

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

Beyond the annotations (readOnlyHint, openWorldHint), the description discloses that data is sourced live from SEC EDGAR, specifies the return shape (filing count and most recent filing date), and explicitly states what is not included. This exceeds what annotations already provide and gives an agent accurate expectations.

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

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

Three sentences with no filler: the core purpose comes first, followed by output details and limitations. Every sentence earns its place and the description is easy to scan 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?

For a simple one-parameter tool backed by rich annotationsrostered, the description is complete: it names the data source, the exact output fields, and the key exclusion. An agent knows what to expect in the response and how this differs from a paid report, with no missing context needed 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?

The input schema already documents the single ticker parameter with an example (AAPL). The description only reinforces that the ticker is US-listed, which adds marginal value beyond the schema. Baseline 3 is appropriate given 100% schema coverage.

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

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

States a specific action ('Look up whether'), a clear resource ('US-listed ticker'), and precise scope ('SEC comment-letter correspondence... form types UPLOAD/CORRESP'). This clearly differentiates it from sibling tools that check accessibility, financial numbers, or other compliance topics.

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 sets expectations: it returns a free-tier preview with only filing count and date, and explicitly excludes letter content or severity scoring. It does not name a specific sibling alternative, but the paid full report reference implies when richer detail would be needed.

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 read-only, open-world, and non-destructive behavior. The description adds useful context: fundamental inputs are not looked up, and the ticker is used only to auto-fill the current price, clarifying data sourcing and side effects beyond what annotations state.

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

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

Two dense sentences with no filler. The formula is front-loaded, and the second sentence gives the essential parameter-use guidance. It does not repeat schema details unnecessarily.

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 is complete enough for a stateless calculator: it explains the model, required inputs, optional price behavior, and the margin-of-safety use case. No output schema exists, but the return value is evidently the intrinsic value per share plus a comparison when a price or ticker is supplied; an explicit return-format description would be the only minor gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by grouping fcf/growth/discount/terminal/years as direct judgment calls rather than lookups, and explains that ticker/price feeds a margin-of-safety comparison. This clarifies the meaning and purpose of the parameters beyond their schema descriptions.

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 ('Compute') and resource ('simplified discounted-cash-flow intrinsic value per share'), and spells out the DCF approach with forward FCF projection, discounting, and Gordon terminal value. This clearly distinguishes it from sibling calculators like Altman Z or Graham Number.

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

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

It explicitly instructs the agent to pass fcf/growth/discount/terminal/years directly as judgment calls and explains the optional ticker/price path for a margin-of-safety comparison. It gives clear context for use but does not name alternative tools or state when not to use it.

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

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

Annotations already declare read-only and non-destructive. The description adds context about the $200/day penalty and the August 1, 2026 requirement, and clarifies that it returns a deadline and checklist items. No contradictions 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?

The description is four sentences, front-loaded with the core purpose. Each sentence adds value: the main function, penalty context, upsell, and legal disclaimer. No unnecessary repetition.

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

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

For a simple two-parameter tool with no output schema, the description adequately specifies what it returns and provides regulatory context. The exact output format (e.g., date format) is not stated, but that is a minor gap given the tool's simplicity.

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

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

Schema coverage is 100% with both parameters already described. The description reiterates the registration date context but adds no new semantic meaning beyond what the schema provides.

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

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

Clearly states the tool takes a registration date and returns the next DROP deadline and first two checklist items. The mention of 'California data broker' and 'DROP' distinguishes it from sibling check tools like accessproof or cloakcheck.

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?

Specifies the intended user (California data brokers) and the required input (registration date), providing clear context. However, it does not explicitly state when not to use this tool or contrast it with alternative compliance tools, so exclusions are absent.

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 mark the tool read-only and non-destructive, and the description adds a live-data caveat and an over-matching behavior warning, telling the agent to review each hit. This is beyond the structured annotations and helps calibrate trust in results.

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

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

Four sentences, each carrying a distinct piece of information: function, return value, when to use, and over-matching caveat. The most critical scoping is front-loaded and no redundant phrases appear.

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

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

For a one-parameter read-only lookup, the description provides the input, output shape, usage triggers, and a behavioral caveat; no output schema is needed because return contents are named. It is self-sufficient for an agent to decide and invoke correctly.

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

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

The schema already documents the dependencies parameter as comma-separated names with an example, so description coverage is 100%. The description's phrase 'matching is by name' reinforces but does not extend the schema, keeping this at baseline.

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

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

The description opens with a clear verb and resource: checking dependency names against CISA's live KEV catalog, and specifies the output (CVE, vulnerability name, why it matched). This distinguishes it from sibling security tools like triageshield and pumpcheck by tying it specifically to CISA KEV and CRA reporting.

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

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

It explicitly says to call it before shipping or during a dependency/security review, and when assessing EU CRA Article 14 reporting triggers. It does not name alternatives to avoid, but gives concrete contexts that select this tool.

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 valuable behavioral context: it automatically looks up data from SEC EDGAR + market data, and it computes both the fair-value ceiling and margin of safety. It doesn't disclose edge cases (e.g., missing data, negative EPS), but for a read-only calculator the description adds meaningful behavioral context 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?

Three sentences with zero waste. The formula is front-loaded, the data sources and invocation mode are stated, and the alternative path is given in one sentence. Every sentence earns its place.

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

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

For a read-only calculator with 100% schema coverage and no output schema, the description is nearly complete. It explains the formula, data sources, both invocation modes, and the margin-of-safety output. It doesn't describe the output format or edge cases (e.g., what happens if ticker data is unavailable), but the annotations and schema cover the safety profile and parameters, so the description is sufficient for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds semantic meaning by explaining the relationship between parameters: eps/bvps/price are used 'instead of a ticker lookup' and price is 'used to compute margin of safety.' This clarifies the two invocation modes beyond what the schema provides, though it doesn't detail validation rules or units.

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 ('Compute'), a precise resource (Benjamin Graham's fair-value ceiling formula), and the scope (US-listed ticker, margin of safety vs current price). It clearly distinguishes itself from sibling calculators like altman-z-score-calculator__compute_altman_z_score and dcf-calculator__compute_dcf by naming the formula and data sources.

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

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

The description explicitly says 'just pass a ticker' for automatic lookup, and explicitly states the alternative: 'You can also pass eps/bvps/price directly to compute it for a hypothetical company with no ticker.' This gives clear when-to-use guidance and distinguishes the two invocation modes. It doesn't name sibling alternatives, but the formula-specific scope makes the usage context clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by describing the report's sourcing (real SEC 10-K figures, not modeled) and analytical content, helping the agent understand what the tool returns. No contradictions 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 paragraph that is informative but somewhat verbose. It front-loads the action but then spends several clauses describing the report's content. While thorough, it could be tightened. Not overly long, but not minimal.

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 tool without an output schema, the description is complete: it states what the tool does, what the report contains, and when to use it. There is nothing an agent needs to know about inputs, and the output is described conceptually. It even clarifies the difference from an LLM-generated summary.

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 does not need to explain any inputs. The baseline for a 0-parameter tool is 4, and the description does not need to compensate for missing schema info. It implicitly treats the tool as a simple informational lookup.

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 ('Get') and resource ('details and pricing for Edge Thirteen's current Industry Primer report'), and clearly describes the report's content and sourcing. It distinguishes itself from an LLM-generated summary and implicitly from the sibling preview tool by emphasizing the real SEC 10-K data.

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

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

Provides a clear use case: investment research needing a sourced industry-level writeup rather than an LLM-generated summary. However, it does not explicitly mention the sibling 'get_primer_preview_table' or give when-not-to-use guidance, so it lacks explicit exclusions or alternative routing.

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 adds meaningful behavioral context: data is sourced from each company's 10-K via SEC EDGAR's XBRL company-facts API, and the operation requires no API key. It also clarifies the table is a free preview and exactly what the paid edition would add.

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

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

Three tightly packed sentences deliver the core retrieval behavior, the returned columns, the data provenance, and the free-vs-paid distinction without redundancy. The most important information is front-loaded in the first sentence.

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

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

With no parameters and no output schema, the description carries full responsibility for explaining the response and it does so by listing the table's columns and their source. The comparison to the paid report closes the main contextual gap an agent might have about what this free tool does not include.

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 already fully documents the input surface. Per the baseline for empty parameter sets, the description cannot add parameter-level meaning, and none 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 uses a clear verb-resource pair: 'Get the free FY2025 preview table' from the Industry Primer, and enumerates the exact columns returned. It also differentiates this tool from the paid report by listing what the paid version adds, so an agent can tell it apart from industry-primers__get_industry_primer_info.

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 explains what the free tool provides versus the paid report, noting the free table is the one already on the tool page and explicitly stating 'Free, no key.' It does not name a sibling alternative by tool ID, but for a zero-parameter lookup the context is sufficient to avoid confusion with the info tool.

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 correctly does not repeat these. It adds behavioral context by stating what the tool returns (0-100 score, band, single most severe flag) and that the full breakdown is a paid $29 report, which is a limitation. The disclaimer that it is 'not a claim about authorship' clarifies what the tool does not do.

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 moderately concise, starting with the primary purpose and patterns, then output, then limitation, then disclaimer. It is front-loaded and each sentence adds value, though it could be slightly tighter. It is well-structured 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 simple single-parameter input and no output schema, the description explains the return values (score, band, flag) and the paid tier, which is important for agent expectations. It also clarifies the non-authorship claim. There is no mention of rate limits or error conditions, but for a read-only analysis tool with one parameter, this is largely 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 100% coverage for the single 'text' parameter with description 'The manuscript or excerpt text to analyze (longer excerpts score more reliably)'. The tool description adds no additional parameter semantics beyond reiterating that it analyzes manuscript text. Baseline 3 is appropriate since schema covers the parameter fully.

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

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

The description clearly states the tool's function: 'Analyze manuscript text for patterns associated with AI-generated prose' and enumerates specific patterns (cliche-phrase density, uniform sentence rhythm, repeated paragraph openers, overused transition words). It also specifies the output (score, band, most severe flag) and disambiguates from the sibling 'slopcheck' (YouTube channel risk) by focusing on manuscripts. The disclaimer 'Not a claim about authorship' further clarifies scope.

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 writers self-editing before publication ('a writer can use to self-edit before publishing'). It does not explicitly name alternatives or exclusions, but the context of manuscript analysis is clear, and no sibling tool directly competes. The paid full-breakdown note also sets expectations about the free vs. paid tiers.

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, which align with the description's claim of just returning script source. The description adds behavioral detail about the optional pre-filling of the script with provided parameters, and describes the return content (script source + setup snippet). This goes beyond annotations without contradiction.

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 paragraph that front-loads the core purpose, then explains the return value and parameter usage. Every sentence adds value, with no redundancy or fluff.

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

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

With no output schema, the description fully specifies what the tool returns (script source and setup snippet). It also explains the optional pre-fill behavior and all parameters are optional, so the description covers everything an agent needs to know to invoke and use the 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?

Schema coverage is 100%, so each parameter already has a description. The tool description adds the crucial context that these parameters are used to pre-fill the returned script, explaining their role beyond mere input fields. This elevates the semantics above the schema baseline.

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

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

The description clearly states the tool retrieves the killcord script, a dead-man's switch for Anthropic API spend. It is distinct from all siblings, which focus on other domains, and the specific verb+resource combination (get killcord script) is 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 conveys the intended use case: stopping a runaway agent loop, and explicitly contrasts it with alerting. While it doesn't name a specific alternative tool, the sibling list shows no similar tool, so the context is sufficient. It lacks explicit 'when not to use' guidance but the purpose is clear enough.

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. The description adds valuable context: the sample is free, requires no key, is already on the tool page, and explicitly lists what the paid kit includes that this sample does not. This goes beyond the annotations without contradicting them.

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

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

Three sentences, each earning its place: the core offer, the bug it addresses, and the boundary with the paid kit. Slightly verbose in explaining the Stripe webhook nuance, but that detail aids specificity and does not feel bloated.

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 sample retrieval with no output schema, the description fully communicates the nature of the sample, its scope, its limitations, and the fact that it is free. The return value is obviously a code sample, so nothing an agent needs to call it correctly is missing.

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

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

The tool has zero parameters and schema coverage is 100%, so the description carries no obligation to explain parameters. It appropriately focuses on the content and limitations of the returned sample rather than input 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?

Clearly states a specific verb+resource: 'Get a free, real code sample from MeterKit' and describes the exact bug fix content. It also distinguishes itself from the paid kit and other MeterKit tools by detailing precisely what this sample is and is not.

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

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

Provides clear context on what this tool returns and explicitly separates the free sample from the paid kit, which helps an agent decide whether this is sufficient. It does not name sibling sample tools, but the distinction between free sample and paid kit strongly implies when to use this.

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 fully covered by structured data. The description adds product attributes (zero dependencies, $99, buyer owns code) and Stripe API context, but these are content details rather than behavioral traits; it does not describe return format or side effects. Given the annotations, 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 description is three sentences with the core purpose front-loaded. The parenthetical about Stripe API version and the product facts add context but are not redundant. It could be tighter, but each sentence provides useful information for an agent deciding whether to call.

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 parameterless read-only info tool with annotations present, the description is complete: it states what is retrieved, product specifics, and the intended use case. No output schema is needed because the first sentence clearly defines the output domain as pricing and details.

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 description carries no parameter burden and schema coverage is trivially 100%. The baseline of 4 applies: there is nothing to compensate for, and the description appropriately focuses on the tool's purpose rather than 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 states a specific verb-resource pair: 'Get pricing and details for MeterKit.' It clearly differentiates from the sibling meterkit__get_meterkit_bug_fix_sample by focusing on product information/pricing rather than sample code. The product category and context are concrete enough for an agent to know exactly what this tool provides.

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

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

The description explicitly identifies a use case: 'Useful for an agent implementing Stripe usage-based billing for its user.' This gives clear context for when to call, though it does not name alternative tools or exclusion conditions. Since the sibling is a different deliverable type, the use-case statement is sufficiently directional.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by naming the data source (SEC EDGAR XBRL), the filing window (most recent 10-K), the specific metrics compared, and the flagging behavior for non-matching claims. 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?

The description is a single dense sentence that front-loads the core action and then efficiently lists the source, filing type, and metrics checked. Every clause contributes, though the long em-dash list makes it slightly harder to parse than a structured two-sentence version would be.

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

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

For a single-parameter, read-only tool with no output schema, the description is largely complete: it specifies what input is expected, what data it is checked against, which metrics are validated, and what the tool does with discrepancies. It does not detail return formatting or edge cases like missing filings, but the core invocation context is clear.

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

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

Schema coverage is 100%, and the schema already describes the text parameter as 'draft text to check, with $TICKER cashtags.' The description reinforces this with the example '$AAPL' and clarifies that the text is financial writing, but it does not add substantially new parameter-level meaning beyond the schema.

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

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

The description names a specific verb ('Check'), a concrete resource (SEC EDGAR XBRL company-facts data for the most recent 10-K), and a clear scope ($CASHTAG-style ticker mentions in financial writing). It lists the exact metrics checked and the outcome (flagging mismatches), which clearly differentiates it from the many other check_* sibling tools.

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

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

The description clearly implies when to use the tool: when a user has a draft financial text containing $TICKER cashtags and wants verification against filed SEC figures. It does not explicitly state exclusions or alternatives, but the use case is unmistakable and specific enough 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 mark it read-only and non-destructive, but the description adds meaningful behavioral detail beyond that: it only flags detectably missing elements, never certifies compliance, and returns statute citations. This prevents an agent from overstating the tool's conclusions and accurately describes its conservative 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?

Three sentences, each earning its place: the first states the core action and output, the second provides the paid alternative, and the third adds behavioral limitations. The main purpose is front-loaded and there is no filler or repetition.

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

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

Even without an output schema, the description explains what the tool returns (missing element plus citation), its limitations (free preview, never certifies, not legal advice), and its scope (four states). For a single-required-parameter read-only tool, nothing essential is missing.

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

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

Schema coverage is 100%, with both parameters already described in the input schema. The description adds useful context about the law subset and required elements, but it does not add material parameter-level meaning beyond what the schema already states. 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 opens with a specific verb ('Scan') and a concrete resource ('a job posting's text'), names the governing laws (CA, CO, NY, WA), and states the exact output: flag missing salary-range or benefits elements with a statute citation. This clearly distinguishes it from the many sibling check tools by subject matter and behavior.

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

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

The description explicitly scopes the tool as a 'free-preview subset' and names the paid full 15-state + DC report as the alternative, with a URL. It also sets expectations with 'Conservative: never certifies a posting as compliant' and 'Not legal advice,' giving an agent clear when-to-use and when-not-to-use guidance.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses exactly what the tool returns: headline count, spike-resistant estimate, busiest-day share, version-flood bursts, and a clean/unreliable/inflated verdict. It also explains the underlying detection mechanism. This is a rich behavioral contract that lets an agent predict the tool's output without an 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?

The description is front-loaded with the core purpose, then the threat model, then the output contract, and closes with usage guidance. Every sentence carries distinct information; there is no filler or repetition of the schema or annotations.

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

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

For a single-parameter, read-only tool with no output schema, this description is complete: it states the goal, the detection rationale, the exact return components, the verdict scale, and the recommended usage moment. An agent can decide to call it and interpret its result without further lookup.

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 only parameter, package, is already described with examples in the schema ('e.g. express or @upstash/context7-mcp'). The description references npm packages generally but adds no additional parameter-specific semantics, so it meets the baseline without exceeding 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 opens with a specific verb and resource: 'Check whether an npm package's public download count reflects real adoption.' It names the concrete phenomenon it detects ('download pumping'), describes the exact output components (30-day count, spike-resistant estimate, busiest-day share, version-flood bursts, verdict), and is clearly distinct from sibling tools like exploitwatch or slopcheck.

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

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

The description explicitly says 'Use before adding or recommending a dependency, especially a new or unfamiliar one,' which gives a clear decision context. However, it does not mention when not to use the tool or name any alternative sibling for comparison, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond those hints: it promises a 'federal-level result now', discloses that state-specific detail is gated behind a $49 report, and includes a 'Not legal advice' disclaimer. 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?

Three sentences cover purpose, output scope/limitation with a link, and legal disclaimer without wasted words. The most decision-relevant information is front-loaded before the paid-report upsell and disclaimer.

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

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

For a tool with 8 parameters and no output schema, the description gives only a vague 'federal-level result' and does not describe the result shape, format, or how the score is presented. Input semantics are well covered by the schema, but the output side is under-specified for an agent deciding whether the returned answer fully satisfies the user's need.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters including required fields. The description itself does not add parameter-level meaning, so the baseline 3 applies.

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

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

The description opens with a specific verb ('Score') and a concrete resource ('a subscription business's signup/cancellation flow') anchored to named laws (FTC Section 5/ROSCA, CA AB 2863, CO SB25-145, etc.). This makes the tool's purpose unmistakable and clearly distinct from the other compliance-check 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?

It clearly conveys when to use the tool: an immediate federal-level check, with the 'full state-by-state breakdown... separate $49 report' acting as an explicit exclusion for deeper state-level needs. However, it does not name an in-catalog sibling alternative or phrase a formal when-to-use/when-not-to-use rule, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: it returns a 0-100 risk score, a band, and only the single highest-severity flag (explicitly noting the full breakdown is paid). This explains a non-obvious limitation that the schema doesn't convey.

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

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

Three sentences, each earning its place: purpose+signals, return values+paywall clarification, and input source. No fluff, front-loaded with the core purpose. The promotional line about the paid product is embedded naturally and also explains why only one flag is returned.

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 a single parameter with 100% schema coverage and no output schema, the description covers everything an agent needs: what it checks, what it returns, and what input to provide. It even addresses the input format explicitly, making the tool fully self-contained.

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

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

Schema coverage is 100%, so the schema fully documents the 'videos' parameter and its nested properties. The description reinforces the field names (caption/postedAt/durationSeconds/format) and clarifies the data source (TikTok Studio's analytics export), adding marginal context beyond the schema. It doesn't introduce new parameter semantics.

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

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

The description states a specific verb ('Spot-check') and resource ('TikTok creator's exported video list') and details the exact risk signals evaluated (repetitive captions, cadence, formats, duration). It clearly distinguishes itself from sibling tools like slopcheck (YouTube) and kdpcheck (manuscripts) by naming TikTok and the Creator Rewards Program.

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 on when to use the tool (when you have a TikTok Studio export of a creator's own videos) and specifies the exact input format. It doesn't explicitly name alternatives or exclusions, but the niche scope makes the intended use obvious. The phrase 'Spot-check' implies a quick assessment rather than a full audit, which is useful guidance.

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

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

Annotations already declare read-only/non-destructive behavior, and the description adds substantial detail: sitemap-first discovery with homepage crawl fallback, a sampled subset, summary-only output without finding text or page locations, and the paid full-report tier. This gives an agent realistic expectations about result granularity and limitations.

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

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

Four sentences, each carrying distinct value: method, return shape, invocation timing, and report limitation/upsell. The description is front-loaded and free of filler, though the final commercial sentence is slightly promotional.

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 one parameter and no output schema, the description adequately explains what is returned (counts, severity counts, categories), what is not returned, and the fallback crawling behavior. Minor ambiguity remains around the exact sample size, but the description is sufficient 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?

The single 'site' parameter is fully documented in the schema with 'example.com' as an address example. The description reinforces 'website address' but adds little format-level detail beyond the schema, so the 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: discover pages from a sitemap or crawl, then check a sample for WCAG 2.1 accessibility and prompt-injection issues. The 'site-wide' framing and 'single-page scan would miss' contrast clearly distinguish it from sibling page-level tools like accessproof and cloakcheck.

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

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

It explicitly says to call this 'before launch or handoff' and explains that it catches site-wide issues a single-page scan would miss. It could be stronger by naming exact alternative tools for single-page checks, but the timing and scope guidance is clear enough.

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 valuable behavioral context: it is a heuristic proxy, not a simulation of YouTube's review process, and it returns a risk band, numeric score, and the single most severe flag. It also discloses that the full flag-by-flag report is a separate paid product, which is important for setting expectations. 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?

The description is two sentences, front-loaded with the core purpose and criteria, then the output summary, then the heuristic caveat and paid-product disclosure. Every sentence earns its place, though the paid-product sentence is slightly promotional and could be trimmed. Still, it is 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?

For a single-parameter read-only tool with no output schema, the description is complete enough: it states inputs, criteria, output shape, and the heuristic nature. It does not specify the exact numeric score range or how many uploads are checked, but those are minor gaps given the tool's simplicity and the annotations covering safety. A 4 is appropriate.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter ('channel') with examples. The description does not add much beyond the schema, but it does imply the channel is a YouTube channel handle/URL/ID, which aligns with the schema. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 ('Check'), a specific resource ('a YouTube channel's recent uploads'), and the specific policy criteria (title/description repetition, upload-cadence regularity, AI-disclosure language). It also clearly distinguishes this from siblings by naming the exact policy and output (risk band, numeric score, most severe flag).

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 implies when to use this tool: when an agent needs to assess a YouTube channel's risk under YouTube's 2026 inauthentic-content policy. It does not explicitly name alternatives or exclusions, but the context signals show many sibling tools with different purposes, and this description is specific enough that an agent can route correctly. It lacks an explicit 'use this instead of X' statement, so not a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds behavioral context: it produces a spend total and overlap count, notes that category recognition is automatic, and clarifies it is a free preview with limited features. This goes beyond the schema and annotations, though it does not describe the exact return format (numeric vs. text) or pagination, which is minor given the simple nature.

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

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

Two sentences, no fluff. The first sentence front-loads the action, input format, and key output; the second clarifies scope (free vs. paid) with a URL. Every part is purposeful and easy to parse.

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

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

With a single parameter and no output schema, the description carries the burden of explaining both input and output. It explains the input format in detail and states the two outputs (spend total, overlap count). It also mentions the paid version's limitations, which is useful context. It does not specify the exact format of the spend total (e.g., currency, monthly vs. annual), but for a read-only, low-complexity tool, this is acceptable.

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

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

Schema coverage is 100% and includes an example, so baseline is 3. The description adds meaning by explaining that common tool categories are auto-recognized, category is optional, and that the tool counts overlapping categories—information that helps the agent understand how the subscription string is parsed and what the output represents. This goes beyond the schema's syntax description.

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

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

The description states a specific verb ('Get') and resource ('spend total for a pasted list of SaaS subscriptions') along with the output ('count of categories with likely overlap'). It clearly distinguishes itself from siblings by focusing on SaaS subscription auditing, which is unique among the listed tools. No ambiguity about what the 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 implies usage context by specifying input format and the free-versus-paid scope. It does not explicitly name alternatives or exclusions, but given the sibling list is entirely different domains (accessibility checks, calculators, etc.), the intended use is unmistakable. Could be improved by a short 'Use this when...' statement, but the context is sufficient.

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 the tool read-only and open-world. The description adds meaningful behavioral context: it checks against live current repository contents, flags mismatches like missing files or past-EOF lines, and explicitly disclaims security-bug judgment. This goes beyond the annotation baseline, though it does not describe the output format.

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

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

Two tight sentences with no filler. The first sentence front-loads the core action and targets; the second sentence clarifies the tool's boundary. Every clause adds value.

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 two fully documented parameters, clear scope, and read-only annotations, the description covers the essential context. The only minor gap is that it does not state the exact return format of the 'flags,' but the phrasing is sufficiently clear for an agent to infer the tool produces a list or indication of mismatched claims.

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 both params ('repo' and 'report'), and the description does not add parameter-specific detail beyond what the schema provides. Baseline 3 is appropriate since the schema already carries the full burden for parameter semantics.

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

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

The description uses a specific verb ('Check') with a precise resource ('a vulnerability report's concrete claims... against a real public GitHub repo's current contents'). It clearly distinguishes this tool from the many other sibling checking tools by focusing on factual verification of codebase claims, not generic vulnerability assessment.

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 states the tool's scope and explicitly excludes judging whether a verifiable claim is an actual security bug, saying it 'only checks whether the claim is honest about the codebase.' While it does not name alternative siblings, this boundary is enough to guide appropriate use without confusion.

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

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

The description goes beyond the annotations by detailing the behavior: it returns counts and sample records per source, and handles unreachable sources by reporting 'not-checked' rather than 'clean.' This is valuable context that the readOnlyHint annotation doesn't cover. It also discloses the scope of what the screen checks, giving the agent a clear picture of what will happen.

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

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

The description is three sentences with no filler. It front-loads the purpose, lists the specific sources, gives usage context, and explains the output behavior. Every sentence earns its place, and the structure is easy to scan.

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

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

Given the complexity of multiple sources and no output schema, the description explains the key aspects: what it screens, what it returns (counts and samples), and how it handles unreachable sources. It doesn't detail the exact output structure, but that is acceptable given the lack of an output schema and the tool's free-screen nature. Minor gaps like pagination or auth are not critical.

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

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

The schema description for the 'name' parameter already covers it fully with a type and example. The description does not add extra semantics beyond what the schema provides, so the baseline of 3 applies. The high schema coverage means the description's job is already done.

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: performing due diligence on a US company by screening against multiple official federal records (SEC EDGAR, OFAC SDN, USAspending, court dockets). The verb 'screens' plus the explicit list of sources and what it extracts (CIK, state, SIC) makes the function unambiguous. It distinguishes itself from the many unrelated sibling tools by naming its specific domain.

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

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

The description explicitly lists when to use the tool: 'before onboarding a vendor, signing a supplier, screening a counterparty or qualifying a sales lead.' This gives clear context. However, it does not mention when not to use it or suggest any alternative tools, though no closely related siblings exist to differentiate from. The guidance is strong but lacks exclusions.

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

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

Beyond the annotations (readOnly, destructive, openWorld), the description discloses that the output is a fixed sample, not a live market run, and that it requires no authentication. It also lists exactly what data is returned, which adds significant behavioral context beyond the simple read-only 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?

The description is well-structured and front-loaded: the first sentence states the main purpose and contents, the second clarifies the sample nature and contrasts with the paid subscription, and the third mentions cost and key requirements. Every sentence earns its place, with no redundancy.

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

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

For a tool with no parameters, read-only annotations, and no output schema, the description fully covers what an agent needs: what is returned, that it is a sample, and that it is free. There is no missing information required to call it correctly.

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

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

The tool has zero parameters and the schema is empty (100% coverage), so there is nothing for the description to clarify about parameters. The baseline for a parameterless tool is 4, and the description adds no unnecessary parameter info.

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: 'Get a real sample run of ValueFeed's Graham/Buffett-style value screen' and enumerates the specific metrics and excerpt returned. It distinguishes this from a live subscription by explicitly labeling it a 'fixed illustrative sample', so the agent understands exactly what it 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 implies usage by contrasting the sample with the paid weekly screen, and notes it is free with no key. It does not explicitly name sibling alternatives like get_valuefeed_info, but the context makes it clear this is for obtaining sample data rather than service information. A slightly more explicit routing to alternatives would warrant a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds context about the product's content (SEC-sourced, screens, metrics, filing excerpts) and its licensing, which helps an agent understand what to expect. It does not describe any additional behavioral traits like response format, but for a get_info tool with no parameters, this is sufficient.

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

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

The description is two sentences with no waste. The first sentence packs the core purpose (product, content, licensing) and the second adds a clear use case. It is front-loaded and efficiently structured, earning a top score.

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

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

With no parameters, no output schema, and annotations covering safety, the description provides all necessary context for an agent to decide when to use this tool. It explains what the tool returns (pricing and details) and gives a practical use case. Nothing essential is missing for a simple get_info 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?

There are zero parameters, so schema coverage is trivially 100%. The description does not need to add parameter meaning because there are none. The baseline for 0 parameters is 4, and the description correctly focuses on the tool's purpose rather than 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 'Get' and the resource 'pricing and details for ValueFeed', and elaborates on what ValueFeed is (a weekly SEC-sourced research packet) and its licensing purpose. This distinguishes it from sibling get_info tools for other products by naming the specific product and its value proposition.

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 a clear use case: 'Useful for an agent helping a finance content creator find raw research inputs instead of raw LLM-generated numbers.' This gives context for when to use it, though it does not explicitly name alternatives or state when not to use it. The sibling valuefeed__get_sample_screen is not mentioned, but the use case makes the intended scenario evident.

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 adds meaningful behavioral context: it is static analysis, does not run a real build, and a clean result is not a deploy guarantee. This is valuable beyond the structured annotations, though rate limits or auth behavior are not mentioned.

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

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

The description is dense but every clause earns its place: purpose, footgun list, static-analysis caveat, and the GitHub alternative are all stated without redundancy. It is front-loaded with the primary action and stays appropriately sized for a tool with this much behavioral nuance.

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

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

For a single-parameter static-analysis tool, the description covers input format, scan scope, and result semantics, including the 'not a deploy guarantee' caveat. With no output schema, the exact shape of findings is left unspecified, but the core information needed to invoke the tool correctly is present.

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

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

The schema covers the single files parameter 100%, so the baseline is 3. The description adds extra value by providing a concrete marker format example and telling the user which files to include (api/*.py plus root manifests), going beyond the schema's generic 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 starts with a specific verb and resource ('Scan pasted project files') and enumerates concrete footgun categories, making the tool's scope unmistakable. It also distinguishes itself from sibling check tools by focusing on Vercel Python-runtime deploy issues. The 'static analysis' clarification further prevents confusion with build/deploy 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 clearly states the intended input modality ('pasted project files') and explicitly routes public GitHub repo scans to an external paid checkout. It does not explicitly say when not to use the tool (e.g., for non-Python projects or when a real build is needed), but the limitation is disclosed.

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