Prism — Data Enrichment for AI Agents

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

No annotations are provided, so the description should disclose behavioral traits. It mentions cost and data sources but does not indicate whether the operation is read-only, what side effects occur, required authentication, or rate limits. While the name implies enrichment (likely a read operation), the lack of explicit safety information is a gap given the absence of 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 concise, using two sentences to convey purpose and cost. The key information is front-loaded. However, it could be restructured to include parameter guidance without increasing length significantly.

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

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

Given the tool's complexity (multiple data points in output) and lack of output schema, the description should explain the return structure. It lists data categories but not details. Additionally, no annotations exist to compensate. The presence of many sibling tools suggests the description should better distinguish the tool's scope. The input parameter is underspecified. Overall, the description is incomplete for safe and effective use.

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

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

The description adds no meaning to the single 'arg' parameter beyond its name. With 0% schema coverage, the description should clarify what format or value the parameter expects (e.g., company name, domain, identifier). The current description only references the profile output, not the input, leaving the agent to guess the correct parameter format.

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

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

The description clearly states the tool provides a firmographic company profile including legal entity, HQ location, funding signals, and government-contractor status from public sources. This specifies the verb (enrich) and resource (company profile), distinguishing it from sibling tools like enrich_domain or enrich_people. However, it does not explicitly state what input the 'arg' parameter represents (e.g., company name or domain), which slightly reduces clarity.

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

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

The description does not provide guidance on when to use this tool versus alternatives. It only mentions the cost range and that data comes from public sources. It fails to differentiate from similar enrichment tools (e.g., enrich_lite, prism_company) or specify scenarios where this tool is preferred. This leaves the agent without decision context.

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

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

With no annotations, the description carries full burden. It mentions cost but omits behavioral traits like required authentication, rate limits, or error handling for invalid domains.

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 brief but includes a cost note that, while useful, is not front-loaded. The phrase 'Lead enrichment +' appears incomplete and detracts from clarity.

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 parameter and no output schema, the description lacks completeness. It does not specify return format or what 'enrichment' entails beyond listed data types.

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 'arg' has no description in schema (0% coverage) and the tool description does not explain what it represents, leaving the agent to guess the domain name.

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

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

The description clearly states it provides domain intelligence with specifics like DNS records, WHOIS registration, and TLS certificate footprint, distinguishing it from sibling tools focused on people or companies.

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

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

No guidance on when to use this tool versus alternatives like enrich_company or enrich_people. The description implies lead enrichment context but lacks explicit usage conditions.

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?

Without annotations, the description discloses that the tool returns probabilistic guesses ('ranked email guesses') and includes live MX validation, giving the agent insight into result reliability. Cost is also noted. However, it does not mention authorization needs, rate limits, or behavior on no match.

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

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

Two concise sentences: first covers purpose and output, second adds cost. No redundant information; every part earns its place.

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

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

For a simple tool with one parameter and no output schema, the description covers input, output nature, and cost. Missing details on error handling or output structure (e.g., rank format) but still fairly 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 input schema has a single generic 'arg' parameter with 0% description coverage. The description adds that it expects 'person name + company domain' but does not specify format (e.g., delimiter, order). This is inadequate for unambiguous usage.

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 'Work-email finder' with inputs 'person name + company domain' and output 'ranked email guesses by real-world frequency + live MX validation.' It distinguishes from siblings (e.g., enrich_people, lookup_email_validate) by focusing specifically on email guess generation.

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 stating inputs and output, but provides no explicit guidance on when to use this tool versus alternatives like enrich_people or lookup_email_validate. No conditions, exclusions, or prerequisites are mentioned.

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

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

No annotations provided, so description carries full burden. It discloses the cost range ($0.005-$0.05 USDC per call) which is a behavioral trait. However, it does not mention rate limits, authentication needs, or whether the operation is read-only. The description implies a read operation but is not explicit.

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 focused sentences: first states purpose, second provides cost. No extraneous information. Front-loaded with key functionality.

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

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

No output schema exists, and the description does not describe return values or structure. Given the variety of data types claimed (domain, social, people, etc.), the lack of output documentation makes it hard for agents to use results. The description is insufficient for a comprehensive tool.

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

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

Schema has one parameter 'arg' with no description and 0% coverage. The description fails to explain what 'arg' should contain (e.g., domain name, company name). Mention of data types like domain, social, people does not clarify the input format. This leaves agents uncertain how to invoke the tool.

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

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

The description clearly states the tool performs company enrichment including domain, social, people, places, and contact data in one call. This distinguishes it from sibling tools like enrich_domain or enrich_people that are more specific.

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

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

No guidance on when to use this tool versus alternatives. While cost is mentioned, there is no explanation of prerequisites, input format, or typical use cases. The incomplete 'gov/' fragment does not provide clear direction.

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?

Description includes cost information ($0.005–$0.05) and implies a lookup operation, but does not explicitly state whether it is read-only or if it modifies data. No annotations provided, so description carries the burden. However, the description is truncated, reducing transparency.

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 short and front-loaded but appears truncated (ends mid-word 'verifi'). For a 1-parameter tool, it is concise yet incomplete.

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?

Description lacks output details (format or structure of results) and does not explain what 'enrich' means beyond finding email/phone. With no output schema, this is a significant gap for a tool with a single parameter.

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

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

The input schema has one undocumented parameter 'arg'. Description adds meaning by giving an example format ('Patrick Collison stripe.com'), but does not formally specify the expected format or delimiters. Schema description coverage is 0%, so description partially compensates.

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?

Description clearly states tool is a work-email and phone finder given name and company domain, with an example. It specifies the verb+resource, but does not explicitly differentiate from sibling tools like enrich_email or enrich_lite.

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

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

No guidance on when to use this tool versus alternatives. The description gives an example input but does not indicate preferred scenarios or 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?

The description mentions extracted content types and includes cost information, but lacks details on failure modes, authentication, rate limits, or input format requirements. With no annotations, it carries the transparency burden but does not fully meet it.

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 with no unnecessary words. The cost line is integrated but could be separated. Structure is effective for a short description.

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

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

Given no output schema and sparse parameter description, the description fails to provide sufficient context for an agent to understand input/output behavior, error handling, or expected results.

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 'arg' has no schema description (0% coverage). The description partially compensates by mentioning 'PDF or document URL', but does not clarify the required format (e.g., URL vs file path), leaving ambiguity.

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 'structured document extraction' and lists specific content types (text, tables, forms, invoice fields) from PDFs or document URLs, distinguishing it from sibling tools like extract_url. However, the truncated phrase 'into LLM-r' slightly reduces clarity.

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

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

No guidance on when to use this tool versus alternatives (e.g., extract_url). It only implies usage for document extraction but does not specify exclusions or prerequisites.

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?

Without annotations, the description carries the burden. It discloses cost range ($0.005–$0.05) and implies a read-only operation (extraction), but does not address potential issues like JavaScript rendering, rate limits, or authentication requirements.

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 short but cut off mid-sentence ('for ag'), reducing clarity. The cost information is embedded but the truncation undermines conciseness.

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?

Despite no output schema, the description explains the output format (markdown with title and main content). However, it lacks details on page size limits, handling of non-HTML URLs, or error scenarios, and the truncation leaves an incomplete picture.

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 0% (no property description), but the description adds meaning by stating the parameter is a 'web URL' (via 'Any web URL -> ...'). This partially compensates, though it could be more explicit about the parameter's role.

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: converting a web URL into clean, LLM-ready markdown by stripping boilerplate and extracting title and main content. This distinct purpose is well-communicated.

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

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

No explicit guidance on when to use this tool versus alternatives like extract_document or prism_scrape. The phrase 'The retrieval/RAG primitive' hints at a primary use case but is incomplete and lacks clear when-not scenarios.

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

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

With no annotations provided, the description carries the full burden but only states it returns snippets (for free), lacking details on side effects, rate limits, or other behavioral traits.

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

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

A single, front-loaded sentence that states the main action and lists platforms without unnecessary words.

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

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

For a zero-parameter, simple tool, the description is largely complete but could mention the output format to aid agent understanding.

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 has no parameters (100% coverage), so the description adds value by specifying the exact platforms and the nature of the output, going beyond the empty schema.

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

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

The description uses a specific verb ('Return') and resource ('ready-to-paste configuration snippets') and lists target platforms, clearly distinguishing it from sibling tools which are data enrichment/retrieval tools.

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

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

The description implies usage (when installation snippets are needed) but provides no explicit guidance on when to use this tool versus alternatives or any 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?

Discloses that the tool is free ('Free — no wallet required'), a key behavioral trait. For a simple list tool with no parameters, this adds value beyond what annotations would provide. No contradictions or omissions noted.

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 wasted words. The purpose and usage are front-loaded, and 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 without an output schema, the description completely covers what the tool does, what it returns (prices, live status), and its role in discovering available tools.

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?

No parameters exist, and schema coverage is 100%. The description doesn't need to add parameter details; a baseline 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 states the verb 'list', the resource 'paid endpoints', and the information returned (prices, live status). It distinctly differentiates from sibling tools, which are data-oriented operations.

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

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

Explicitly says 'Use this first to discover what tools are available,' providing clear when-to-use guidance. No exclusions or alternatives are mentioned, 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?

No annotations are provided, so the description must disclose all behavioral traits. It mentions the actions and cost, but lacks details on auth requirements, rate limits, error handling, or whether it modifies anything. The description is truncated ('returning th'), missing return value 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 extremely concise with two sentences and no fluff. However, it appears truncated, which is a defect rather than conciseness—hence the score remains high as the intended text is efficient.

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

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

Given no output schema, the description should explain return values, but it is truncated ('returning th'). It also omits error scenarios and edge cases. For a simple tool with one parameter, this is insufficient.

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 0% schema description coverage, the description must compensate. It implies the 'arg' parameter is the email address to validate, but does not specify expected format, constraints, or examples. This adds some meaning but is insufficient for full clarity.

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 performs an 'email deliverability check' with specific actions: syntax validation and live DNS/MX lookup. It distinguishes from sibling tools which are primarily enrichment, search, or extraction 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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use, or comparison with other tools.

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

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

No annotations exist, so the description must disclose behavior. It only mentions cost range and the data source (Google News), but lacks details on time range, pagination, limits, authentication, or any side effects.

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

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

The description is brief with two sentences and a cost line, front-loading the core functionality. Every sentence adds value, though a more structured format could enhance readability.

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 simplicity (1 param, no output schema, no annotations), the description covers the basic purpose and return fields. However, it lacks details on expected output format and usage parameters, making it only minimally adequate.

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

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

With 0% schema description coverage, the description must explain the sole parameter. It implies 'arg' is a topic but provides no format, example, or constraints, leaving ambiguity.

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

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

The description clearly states it returns recent news headlines for a topic with specified fields (title, source, date, link) via Google News. It is distinguishable from sibling enrichment/search tools by its focus on news headlines.

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 mentions 'Monitoring primitive for agents' hinting at periodic use, but does not provide explicit guidance on when to use this versus other tools like search_web. Cost information is included but does not address context or scenarios.

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

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

With no annotations provided, the description carries the full burden. It states the tool returns pricing details and mentions 'Free.', which hints at no cost. However, it does not disclose other behavioral traits like whether it counts towards API usage limits or if authentication is needed. For a simple, parameterless tool 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?

Two sentences, very concise. The first sentence front-loads the purpose. Every word earns its place. No wasted 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?

Given the simplicity of the tool (no params, no output schema, no annotations), the description is complete enough. It tells what the tool returns. It could optionally mention the response format, but that is minor 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?

There are zero parameters, and schema description coverage is trivially 100%. The description adds meaning by explaining what the output will contain (base price, etc.), which goes beyond the empty schema. Baseline for 0 parameters is 4, and this description meets it.

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

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

The description clearly states it returns pricing details for the GoCreative Agent API, specifying exactly what details (base price, premium endpoints, cache TTLs, payment networks). This is a specific verb+resource and distinguishes from all sibling tools, none of which are pricing-related.

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

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

The description implies the tool should be used when pricing information is needed. Given that no sibling tool has a similar function, the context is clear. However, it does not explicitly state when not to use it or mention any alternatives, but that's less critical here.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It mentions keyless access and pricing, but fails to disclose any side effects, authentication requirements, rate limits, or error handling (e.g., behavior on invalid domains). The description does not contradict provided annotations, but it is insufficiently transparent.

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

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

The description is extremely concise: two sentences with no wasted words. The first sentence immediately states the tool's function and scope, and the second adds relevant cost information. Every sentence earns its place.

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

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

Given the tool's simplicity (one parameter, no output schema), the description adequately outlines the tool's function and the types of data returned (legal entity, DNS/WHOIS, etc.). However, it lacks details on return structure, data freshness, or what constitutes a successful call. It is minimally complete but not exhaustive.

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

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

The only parameter is 'arg' with no schema description. The description clarifies that 'arg' expects a domain, adding meaning beyond the generic parameter name. However, it does not specify the required format (e.g., with or without protocol) or provide any constraints or examples. The 0% schema coverage demands more, but the description partially compensates.

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: firmographic enrichment for any domain, listing specific data types (legal entity, DNS/WHOIS, TLS, web footprint). This clearly distinguishes it from sibling tools like enrich_domain or enrich_company_profile by focusing on firmographic data derived from a 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 provides no guidance on when to use this tool versus alternatives. It mentions cost and keyless access but does not explain when this tool is preferred over similar tools like enrich_company_profile or lookup_email_validate. No usage context or exclusions are given.

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 behavioral details like pattern frequency ranking and live MX verification beyond the bare tool name. However, it omits information on authentication, rate limits, and error behavior. Annotations are absent, so the description carries full burden but is only partially informative.

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

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

The description is extremely short (one sentence plus cost note) but is cut off mid-word ('live MX v'), which harms readability. It is concise but not well-structured, and the cost inclusion is unconventional.

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 low schema coverage, absent annotations, and missing output schema, the description does not adequately cover input formatting, output structure, or error handling. It is insufficient for the agent to use the tool reliably.

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 'arg' parameter has 0% schema description coverage and the description only mentions 'name + company domain' without specifying the expected format (JSON, string, delimited?). This leaves the agent unable to correctly construct the input.

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 finds a person's likely work email from name and company domain, with ranking by pattern frequency and live MX verification. It uses a specific verb-resource combination and distinguishes from sibling tools like enrich_email or lookup_email_validate.

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 (when you have a name and company domain) but provides no explicit when-not-to-use guidance or comparison to alternatives. The use case is clear but lacks exclusionary criteria.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It mentions keyless access and pricing but does not describe any side effects, data mutation, rate limits, or required permissions. The cost info is useful but insufficient for full transparency.

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 short and includes pricing, but it appears truncated ('undercu'). It uses a bullet-like style but loses completeness. A few sentences would be acceptable if not cut off.

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 simplicity of the tool (one parameter, no output schema), the description is somewhat adequate but lacks detail on return format, error handling, or example results. It does not fully equip an agent to handle edge cases.

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 0%, so the description must explain the 'arg' parameter. It states the query can be a name, address, category, or coordinates, which adds some meaning. However, it does not specify format, separators, or if multiple inputs are combined.

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?

Description clearly states the tool is for business places & locations based on a name or query, specifying query types like address, category, coordinates. It distinguishes the tool's purpose from generic search tools, though it could be more explicit about what constitutes a 'place'.

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

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

No guidance is provided on when to use this tool versus siblings like 'search_places' or 'prism_search'. The description does not indicate prerequisites, limitations, or context-specific recommendations.

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

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

With no annotations, the description carries the full burden. It discloses cost and keyless usage, but does not address limitations, error handling, output format, or whether JavaScript rendering is supported.

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 short but appears truncated ('undercuts comp...'), which reduces clarity. The main action is front-loaded, but the incomplete cost line hurts conciseness.

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

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

For a simple tool, the description covers core functionality and cost, but lacks explicit parameter mapping, output format, and differentiation from siblings. No output schema exists to supplement.

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 description implies the single parameter 'arg' is a URL, but does not explicitly state that or provide format details. Schema_coverage is 0%, so description partially compensates but is not thorough.

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 turns a URL into clean structured content (title, text, metadata, links). However, it does not distinguish this tool from siblings like extract_url or extract_document, which may have overlapping functionality.

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

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

No guidance on when to use this tool instead of siblings. The description mentions cost but does not provide context for selection among alternatives.

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

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

No annotations are provided, so the description carries the full burden. It mentions cost but does not disclose rate limits, error handling, pagination, or ordering behavior. Only output types are listed.

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

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

The description is a single sentence with pricing details, which is concise but includes promotional cost information that may not be essential for tool invocation.

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 undocumented parameter and no output schema, the description fails to explain input format, return structure, or constraints. It is insufficient for reliable agent 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 parameter 'arg' has no description in the schema (0% coverage). The description does not clarify what 'arg' represents, leaving the agent to guess it's the search query.

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

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

The description clearly states it performs web search for any query and returns ranked results with titles, URLs, and snippets. However, given sibling tool 'search_web', there is no differentiation or distinction provided.

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

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

No guidance on when to use this tool versus alternatives like 'search_web', 'search_github', or 'search_places'. The description does not specify prerequisites or 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?

With no annotations, the description carries the burden. It discloses keyless access and cost, but does not mention rate limits, data freshness, error handling, or whether the call is read-only. The behavior is partially transparent but lacks depth.

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 explains purpose and outputs, the second mentions cost. It is extremely concise, front-loaded, and contains no redundant 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?

Given the simple input (one string parameter), no output schema, and low schema coverage, the description covers essential elements: purpose, output fields, and cost. It could be more complete by specifying handle format and supported platforms, but it is largely adequate.

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

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

Schema coverage is 0% for the only parameter 'arg'. The description adds meaning by specifying 'by handle', clarifying that arg is the social handle. This compensates for the lack of schema documentation, though the format (e.g., @username) is not specified.

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: 'public social profile lookup by handle' and lists the data returned (display name, bio, follower/post counts). This verb+resource specification distinguishes it from sibling tools like enrich_company or prism_company, which handle different data types.

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 mentions 'Keyless' and cost, implying no authentication needed. However, it provides no explicit guidance on when to use this tool vs alternatives (e.g., prism_contact for contact info, prism_search for broader search). Usage context is implied but not fully defined.

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

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

No annotations provided, so the description carries full burden. It discloses cost range ($0.005–$0.05) which is useful, but lacks information on rate limits, authentication, side effects, or result 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 sentences covering purpose and cost, but the first sentence is truncated. For a tool with one parameter and no output schema, this is acceptable but could be more polished.

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

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

No output schema, no return value description, and parameter semantics missing. Given the tool's complexity (multi-platform results), the description omits critical details like result structure, pagination, or error handling.

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 required parameter 'arg' has zero description in both the schema and the description. The description does not explain what 'arg' should contain (e.g., query string, format), providing no assistance 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?

Description clearly states it's a multi-platform meta-search covering web, GitHub, Hacker News, Stack Overflow, arXiv, academic papers, Wikipedia, news, effectively differentiating from sibling search tools. However, the sentence is truncated, which slightly reduces clarity.

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

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

No explicit guidance on when to use this tool versus alternatives like search_web, search_github, or research_papers. The description implies a broad search but fails to specify scenarios or 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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions cost and data source (Crossref) but does not state whether it is read-only, requires authentication, has rate limits, or what side effects occur. This is insufficient for safe agent usage.

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 brief (two sentences) and to the point. Every sentence contributes: purpose and cost. However, it could be more structured (e.g., explicit verb) and still concise.

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

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

Given no annotations or output schema, the description should cover input format, pagination, rate limits, and behavioral details. It only covers fields returned and data source, missing critical context for an agent to use it effectively.

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 sole parameter 'arg' is described only as 'for a query' in the description, giving some meaning. However, with 0% schema description coverage, the description should provide more detail on the expected format or examples. The current info is minimal but not completely useless.

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 it retrieves recent academic papers with specific fields (title, authors, etc.) via Crossref. The verb is implicit ('papers for a query' implies search/fetch), which is clear but not explicit. Sibling tools like 'research' or 'search_web' are different enough, so differentiation is adequate.

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

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

No guidance on when to use this tool versus alternatives, or when not to use it. The cost information is provided but does not address usage context or prerequisites.

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?

Without annotations, the description provides some behavioral insight: results are top repos by stars, and cost is mentioned. However, it does not disclose limitations such as result count, pagination, data freshness, or authentication requirements, leaving gaps.

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, with a single sentence clearly stating the tool's function and returned data. The cost note is appended without clutter. Information is front-loaded and well-organized.

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

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

Given the tool's simplicity (one parameter), the description provides adequate context: purpose, return fields, and cost. However, it omits details like number of results, explicit ordering (though implied), and filtering. For a complete understanding, an output schema would help, but the description is fairly sufficient.

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

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

The input schema has one parameter (arg) with no description. The description clarifies that 'arg' is a keyword for the search, adding essential meaning. With 0% schema coverage, this is sufficient for understanding the parameter's purpose.

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 performs GitHub repository discovery, returning top repos by stars with specific fields (name, language, description, forks, topics) for any keyword. This distinguishes it from sibling tools like search_web or search_places.

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

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

No explicit guidance on when to use this tool versus alternatives. While it is implied for GitHub-specific queries, there is no mention of when not to use it or what other tools might be more appropriate. The description lacks usage context.

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 mentions the cost ($0.005–$0.05 per call), which is useful, but it does not disclose other behavioral traits such as rate limits, whether it is read-only, or any side effects. Since no annotations are provided, the description carries the full burden but only partially addresses behavioral transparency.

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 short but includes cost information, which is valuable. However, it is not front-loaded with the most critical information (e.g., what the input should be), and the structure could be improved.

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

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

Given the lack of output schema, missing parameter description, and no annotations, the description is incomplete. It does not specify the output structure or how inputs should be formatted, leaving significant gaps for an agent to 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?

The input schema has one parameter 'arg' with no description, and the tool description does not explain what the parameter should contain (e.g., address, place name). With 0% schema description coverage, the description fails to add meaning to the parameter.

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

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

The description clearly states it performs place/address geocoding using OpenStreetMap and returns full address, category, lat/lng. It is specific and distinct from sibling tools like search_web or search_github, though there is a similar prism_places tool that may overlap.

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

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

No guidance on when to use this tool versus alternatives. The description only mentions 'For maps, logistics' as a use case but does not specify when not to use it or mention any sibling tools as alternatives.

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

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

No annotations provided, so description carries full burden. Mentions cost and result format, but omits crucial details: idempotency, read-only nature, error handling, rate limits, or pagination behavior. Significant gaps.

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 punchy sentences with high signal-to-noise ratio. Cost information is a valuable addition. No wasted words.

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

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

Given simplicity (1 param no output schema), description adequately covers purpose and result structure. Cost info adds practical context. However, lacks default result count and potential filters, which could be inferred.

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 has 0% description coverage for the sole parameter 'arg'. Description only adds 'for any query', providing minimal semantic value beyond the schema. No format, length, or encoding hints.

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?

Description clearly specifies 'Web search' with result format (ranked, title/URL/snippet). Emphasizes its role as 'core agent discovery primitive for lead-gen', distinguishing from sibling tools like search_github and search_places.

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?

Implies usage for general web search and lead generation, but no explicit comparison with specialized sibling tools (e.g., search_github, news_headlines). Lacks 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?

No annotations are provided, so the description bears full responsibility. It indicates the tool returns stats, is free, and is for verification. For a read-only tool, this is sufficient.

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

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

Two concise sentences. First sentence states what it does, second provides usage guidance. No wasted words.

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

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

With zero parameters and no output schema, the description provides all necessary information: what stats are returned and why to use it. Fully adequate.

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

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

The tool has zero parameters, so baseline 4 applies. The description does not need to add parameter information.

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

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

The description clearly states it returns summary stats of server usage, including top tools called, success rate, and recent activity. This distinguishes it from sibling tools which are data enrichment or search tools.

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

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

It explicitly states a use case: 'Use to verify your own integration is hitting the right tools.' While it doesn't list when not to use or alternatives, the context makes the diagnostic purpose clear.

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

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

No annotations are provided, so description carries the full burden. It discloses that the tool returns instructions (read-only) and is free. No hidden behaviors suspected given zero parameters and simple functionality.

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 first sentence states purpose, second gives use cases, third notes cost. Front-loaded and every sentence earns its place.

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

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

Given zero parameters, no output schema, and no annotations, the description covers the essential aspects: purpose, when to use, and that it's free. The output format (step-by-step instructions) is implied and sufficient.

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?

No parameters exist, and schema coverage is 100% (trivial). The description adds no parameter info, which is appropriate. Baseline score of 4 is used for zero-parameter tools.

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

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

The description explicitly states it returns step-by-step instructions for setting up x402 USDC autopay, which is a specific verb+resource. It clearly distinguishes from all sibling tools (enrichment, search, etc.) by being the only payment setup tool.

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

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

Explicitly says to use if a paid tool returned a 402 error or when onboarding a new agent for API payments. Does not state when not to use, but sibling tools are unrelated, making the context clear.

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