Data Gov In

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

Annotations already indicate read-only and idempotent behavior. The description adds transparency about probing multiple models, requiring an API key for Anthropic, and the return format. No contradictions found.

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 flows logically from purpose to parameters to use cases. It is not overly long and all sentences contribute 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?

Given the tool's moderate complexity (4 params, no output schema), the description covers the return structure and use cases. Missing details on error handling would improve completeness, but it is adequate.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the default model, how _apiKey works, and the purpose of 'context' for disambiguation.

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 probes LLMs for knowledge about an entity and scores visibility, with a specific verb and resource. It distinguishes itself from siblings like 'scan_competitor_ai_presence' by being a general visibility check.

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 explains when to use the default model versus Anthropic with a BYO API key, and gives clear use cases like AI-marketing audits. It lacks explicit exclusions or comparisons to alternatives but provides sufficient 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?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral details: routing to one of 2,867 tools, filling arguments, and returning structured answers with stable citation URIs. This goes beyond what annotations 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?

The description is a single paragraph front-loaded with key advice ('PREFER OVER WEB SEARCH'). It is reasonably concise; every sentence adds value (types of data, mechanism, usage instructions, examples). Could be more structured, but is effective.

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

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

Given one parameter and no output schema, the description covers purpose, input examples, processing mechanism, and output format (structured answer with citations). It omits error handling or limitations, but is sufficiently complete for a simple 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 coverage is 100% with the parameter 'question' described as 'Your question or request in natural language'. The description repeats this natural language concept and gives examples, but adds no new 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 clearly states the tool's purpose: answering factual questions using authoritative structured data. It specifies verb+resource examples ('what is', 'look up', 'find') and explicitly distinguishes itself from web search, which differentiates it from siblings.

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

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

The description provides clear context on when to use the tool ('for questions about current or historical data...' and 'Use whenever...'). It gives examples but does not explicitly exclude alternatives from sibling tools, though it strongly implies preference over web search.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds extra safety and behavior details: low-confidence resolution short-circuits, closed markets skip fan-out, and wide-spread markets carry tradeability notes. This goes beyond annotations and provides critical context for agent decision-making.

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 detailed but well-structured. It starts with the primary purpose, then explains process, classifiers, fan-out examples, response shapes, and safety notes. While lengthy, each part contributes to clarity. It is front-loaded with the core action 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?

The tool is complex with no output schema, but the description covers inputs, process, response shapes (market, analysis, evidence), safety mechanisms, and error states. It is sufficient for an agent to understand and invoke the tool correctly. Minor omission: exact structure of evidence packet is not detailed, but keyed by source is mentioned.

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 high coverage (100%) with clear descriptions for each parameter. The description adds further context by explaining the default depth ('thorough'), the purpose of include_raw, and providing fan-out examples that clarify how depth affects behavior. This adds value beyond the schema.

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

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

The description clearly states the tool's purpose: to research a Polymarket bet by pulling Pipeworx data. It specifies inputs (slug, URL, question text), outlines the process (resolve, classify, fan-out, return evidence packet and comparison), and distinguishes itself from sibling tools like polymarket_edges by focusing on in-depth research for specific bets.

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

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

The description explicitly states when to use the tool: 'Use for 'should I bet on X', 'what does the data say about Y', or 'is there edge in Z''. This provides clear context. It does not explicitly mention when not to use or name alternatives, but the use cases are well-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?

The description adds significant behavioral context beyond the annotations: for companies it explains the data source (SEC EDGAR/XBRL), the fix for off-calendar fiscal years, and the metrics (revenue, net income, etc.). For drugs it details FAERS, FDA approvals, and trials. It also mentions return format (paired data + citation URIs) and sorting 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 a single, dense paragraph that front-loads the main purpose. Every sentence adds useful information, though it could be broken into bullet points for easier scanning. It avoids 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?

Given the complexity of two entity types and no output schema, the description adequately explains the output (paired data, sorted by primary metric, with citation URIs). It covers the main behavioral aspects but omits error handling or what happens if entities are not found, which is acceptable for a read-only tool with open world hint.

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 100% schema coverage, the baseline is 3. The description adds value by explaining the meaning of values (tickers/CIKs vs drug names), the range (2-5), and providing examples for both types. This gives additional clarity beyond the 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 clearly states the verb 'compare', the resource 'entities' (companies or drugs), and the scope (2-5). It provides specific use cases like 'compare X and Y' or 'which is bigger', and distinguishes from siblings by noting it replaces 8-15 sequential lookups.

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 when to use the tool (for comparison and ranking queries) and differentiates between company and drug types with their respective data sources. However, it does not mention when not to use it or suggest alternative tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and no destructiveness. The description adds that the tool returns the top-N most relevant tools with full schemas and that each result is ready to call directly, providing behavioral context beyond the annotations. No contradictions.

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 reasonably concise, front-loading the primary purpose. The list of example domains is helpful for an agent to understand the scope, though slightly long. Every sentence 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 no output schema, the description adequately explains what the tool returns (names, descriptions, full schemas) and that results are ready to call. It covers input behavior and output format completely for a discovery 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 coverage is 100%, so the schema already documents both parameters well. The description mentions 'top-N most relevant tools' which relates to the limit parameter, but does not add significant new semantic meaning beyond the schema descriptions and examples.

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

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

The description clearly states that the tool finds tools by describing a data or task, listing many specific domains. This differentiates it from all sibling tools, which are domain-specific tools themselves. The verb 'discover' and resource 'tools' are specific and unambiguous.

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

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

The description explicitly says 'Call this FIRST when you have many tools available and want to see the option set', providing clear guidance on when to use. However, it does not mention when not to use or explicitly contrast with alternatives, though the context of discovering tools implies it should be used before direct domain tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds significant behavioral context: that the tool replaces many calls, that patents are deprecated (soft-fail), that fundamentals use sorted data with a note about stale numbers, and that news uses a fallback. This exceeds bare annotations but doesn't cover every possible behavior (e.g., no explicit mention of rate limits or authentication).

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 relatively long with multiple clauses and parenthetical notes. While it is front-loaded with the main purpose, the paragraph could be tightened. Some details (e.g., the patent sunset note) are important but could be presented more succinctly. It is adequate but not optimally concise.

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

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

Given that there is no output schema, the description does a good job explaining return values: cik, company_name, recent_filings with URIs, fundamentals with sort order, patents status, news fallback, and LEI. It covers edge cases (patents deprecated, fundamentals date fix) and provides context for using the tool effectively. A 5 would require even more detail (e.g., pagination, error handling), but this is solid.

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 100% description coverage, with clear explanations for both 'type' (only 'company' supported) and 'value' (ticker or zero-padded CIK). The description reinforces this with an example ('AAPL' or '0000320193') and adds the caveat about names not supported and recommending resolve_entity. This adds meaning beyond the schema, hence a 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 defines the tool's purpose: 'Get everything about a US public company in one call.' It specifies the verb (get), resource (US public company), and distinguishes from siblings by noting it replaces 10+ pack tools. The return fields are explicitly listed, providing a clear picture of 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 provides explicit guidance on when to use the tool: 'Use when a user asks "tell me about X", "research Acme", "brief me on Tesla", or you'd otherwise call 10+ pack tools.' It also states what not to do: 'Names not supported (use resolve_entity first).' This clearly differentiates from sibling tools like resolve_entity.

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 destructiveHint=true and idempotentHint=true. Description adds minimal behavioral info beyond 'delete' and usage scenarios. No contradictions.

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

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

Three concise sentences front-loaded with purpose. No unnecessary words, every sentence 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?

For a simple 1-parameter tool with annotations, description covers usage scenarios and pairing with siblings. Lacks return value info, but no output schema exists.

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 description repeats the parameter's purpose ('by key'). Description adds no new meaning beyond the schema's 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?

Description clearly states 'Delete a previously stored memory by key', specifying the verb, resource, and method. It distinguishes from siblings 'remember' and 'recall' by mentioning them as companions.

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 states when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. Provides context but no explicit when-not-to-use or alternatives, though sibling tools are listed.

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 note idempotent, read-only, and non-destructive nature. The description adds behavioral details: fetching the page, extracting title/description/links, and emitting standard Markdown. It does not contradict 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?

Two concise sentences plus a targeted 'Useful for' bullet. Every sentence adds essential information 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?

Given the tool's simplicity (2 params, no output schema, clear annotations), the description covers purpose, behavior, and use cases adequately. It could note network requirements, but that is implicit from 'fetches the page'.

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 100% coverage, describing both parameters. The description adds value by linking 'key links' to the max_links parameter, clarifying its purpose in limiting link entries.

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 generates a production-ready llms.txt file for any URL. It specifies the output format and the process (fetch, extract, emit). This distinguishes it from sibling tools like scan_competitor_ai_presence by focusing exclusively on llms.txt 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 lists three explicit use cases: getting a client's site indexed, drafting for own projects, and auditing competitor visibility. It implies when to use but does not exclude alternatives or mention when not to use, which would enhance clarity.

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 context beyond annotations: rate-limited to 5 per identifier per day, free, doesn't count against tool-call quota, and team reads digests. 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 concise at about 5 sentences, front-loaded with purpose, and uses clear structure. Every sentence adds value without redundancy.

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

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

Given no output schema, the description covers what happens after submission (team reads digests, affects roadmap) and includes rate limits and quota info. It is fully adequate for a feedback tool.

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

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

The input schema is fully covered (100% descriptions), but the description adds helpful usage guidance: specify tools/packs, don't paste user prompt, 1-2 sentences typical. This supplements the schema beyond basic parameter types.

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 is for reporting bugs, features, data gaps, or praise to the Pipeworx team. It uses specific verbs and examples, and distinguishes it from other tools in the catalog.

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 tells when to use each feedback type (bug, feature, data_gap, praise) and what not to do (don't paste user prompt). It also mentions rate limits and that it's free and doesn't count against quota.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by disclosing caching behavior (5min-1h) and data source (CF analytics-engine, no PII), which are 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 focused sentences plus a concise bulleted list of use cases. 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?

For a simple tool with one optional parameter, the description covers purpose, use cases, data provenance, and caching. While output format is not explicitly described, it's inferable from the stated outputs (top tools, packs, call volume).

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 description already explains the window parameter's meaning and defaults. The description repeats this information without adding new semantics, so baseline score of 3 is appropriate.

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

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

The description immediately states what the tool does: returns top tools, packs, and call volume over a recent window. This clearly identifies the resource and action, distinguishing it from siblings like 'discover_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?

Three specific use cases are listed (discovering hot data sources, confirming canonical choice, aligning use case with demand), providing clear context for when to use the tool. However, no explicit 'when not to use' or alternatives 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?

The description fully discloses the tool's behavioral traits: it is read-only, idempotent, and non-destructive (consistent with annotations). It details the algorithmic checks, similarity threshold, partition filtering, and response structure, adding significant context beyond what annotations provide.

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

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

The description is well-structured and front-loaded with the tool's purpose. It uses clear sectioning (TWO MODES) and provides all necessary details without redundancy. Every sentence adds value, making it efficient despite its length.

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

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

The description covers all aspects needed for an agent to understand and use the tool correctly: input modes, algorithmic details, constraints (similarity, placeholder filter), and output structure (opportunities, partition_check). It compensates for the lack of an output schema by describing the response fields.

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 100% schema description coverage, the baseline is 3, but the description adds substantial meaning by explaining the purpose and logic of each parameter ('event' for single-event mode, 'topic' for cross-event mode). It elaborates on how each mode works, including the partition check and semantic anchor.

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: finding arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes two modes (event and topic) and explains their specific use cases, effectively differentiating from 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 provides clear guidance on when to use each mode (event vs. topic) and explains that cross-event mode catches patterns missed by single-event mode. However, it does not explicitly mention when not to use the tool or provide direct comparisons with siblings like polymarket_edges or polymarket_kalshi_spread.

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 indicate read-only, open-world, idempotent, non-destructive behavior. The description adds substantial behavioral context: details on three model families, edge computation (slippage, Kelly fractions), caching at KV level, and exclusion of fed_rate bets from ranking. No contradictions, and the description significantly enhances transparency 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 long but well-structured, starting with purpose, then model families, output fields, knobs, caching, and exclusions. It is dense with useful information and front-loaded with the main goal. While a bit lengthy, it earns its length given the tool's complexity. Minor points off for verbosity in technical details.

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 specifies return fields (edge_pp_net, kelly_fraction, etc.) and explains all parameters. It covers tradeable-edge filters, caching, and exclusions. For a tool with 9 parameters and complex model families, it is nearly complete. A small gap is lack of explicit output structure (e.g., array of objects), but it is implied.

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 description's parameter section adds value by explaining tradeable-edge knobs and differentiating min_kelly vs min_partition_leg_kelly. It provides context like slippage defaults and suggestions, which goes beyond the schema descriptions. However, the schema already covers each parameter well, so the added value is moderate.

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 scans Polymarket markets for opportunities where Pipeworx data disagrees with market price. It details three segments (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT), providing a specific verb and resource. While it distinguishes from generic tools, it does not explicitly differentiate from the sibling tool 'polymarket_arbitrage', so it loses the top score.

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

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

The description is built for 'what should I bet on today' and guides agents to discover opportunities without paging hundreds of markets. It explains tradeable-edge knobs and caching, providing clear context for use. However, it does not explicitly state when to avoid this tool or mention alternatives, missing some exclusion 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 indicate read-only and idempotent. Description adds significant behavioral context: explains return format (prices as probabilities, spread in percentage points), mode behavior, and that explicit parameters override topic. No contradictions.

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?

Well-structured with core concept first, then modes, then returns. Slightly verbose but each sentence 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?

Despite no output schema, description explains return format sufficiently. Covers both modes and override logic. Adequate for a read-only data retrieval 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 coverage is 100% with descriptions. Description adds further meaning by explaining the two modes and how explicit parameters override topic, and lists pre-mapped topics.

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 it's a cross-venue spread tool between Kalshi and Polymarket, explaining the arbitrage signal. Distinguishes itself from siblings like polymarket_arbitrage by focusing on cross-venue comparisons rather than intra-venue.

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 describes two modes (topic and explicit) with clear instructions on when to use each. Does not name alternative tools but context implies purpose differentiation.

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, idempotentHint, destructiveHint. Description adds scoping to identifier and pairing with remember/forget, which is useful but not critical.

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

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

Three concise sentences, front-loaded with main purpose, then use examples, then scoping. No 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?

For a simple read tool with 1 optional param and no output schema, the description covers usage, scoping, and relationships. Complete for the complexity.

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

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

Schema coverage is 100% and description reiterates the omit-to-list behavior. Adds examples and context of previous save, but does not significantly enhance schema meaning.

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 retrieves a saved value or lists keys, distinguishes from remember and forget siblings. Specific verb 'Retrieve' and resource 'value previously saved via remember'.

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 use cases (look up target ticker, address, notes) and guidance to omit key for listing. Lacks explicit when-not-to-use conditions, but context from sibling tools fills the gap.

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

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

Annotations already mark it as readOnly, non-destructive, etc. The description adds crucial behavioral details: parallel fan-out to SEC EDGAR, GDELT with GNews fallback on rate limits, USPTO patent soft-fail, and return format with citation URIs. 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?

Single paragraph, dense but not verbose. All sentences earn their place. Could be slightly improved with bullet points for the fan-out sources, but remains readable and front-loaded with purpose.

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 tool with 3 parameters and no output schema, the description covers everything an agent needs: input semantics, source behavior, return structure (changes grouped by source, count, URIs), and fallback logic. No gaps remain.

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% but description enriches each parameter: explains 'since' format (ISO date or relative shorthand like '7d', '30d', '3m', '1y') with recommended default '30d' or '1m', and clarifies 'value' can be ticker or zero-padded CIK. These details are absent from the 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?

Description opens with 'What's new with a company in the last N days/months?' and gives concrete use cases like 'what's happening with X' and 'news on Apple this month'. It explicitly contrasts with sibling tool entity_profile, making the purpose and scope crystal clear.

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

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

Provides explicit when-to-use guidance (updates, news monitoring) and when-not-to-use (static profile → entity_profile). Also details the parallel fan-out to multiple data sources and fallback behavior (GDELT→GNews), helping the agent decide when to invoke.

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 (idempotentHint: true, destructiveHint: false) are supplemented by description details: scope by identifier, persistence for authenticated users, 24-hour retention for anonymous sessions. Adds behavioral context 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?

Every sentence adds value, and the description is front-loaded with purpose. It is moderately sized but efficient. Minor redundancy could be trimmed, but overall 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?

Despite lacking an output schema, the description fully explains the tool's behavior, scope, and pairing with siblings. No gaps remain for a data storage 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 covers 100% of parameters with clear descriptions. The description adds no additional meaning for the parameters themselves, so it meets the baseline expectation. No need for extra detail.

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 'Save data the agent will need to reuse later' and provides concrete use cases (resolved ticker, target address, user preference). It distinguishes itself from sibling tools 'recall' and 'forget' by mentioning pairing.

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 provides when to use ('when you discover something worth carrying forward') and mentions alternatives ('Pair with recall to retrieve later, forget to delete'). This gives clear contextual 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 indicate readOnly, idempotent, openWorld, non-destructive traits. The description adds that each call cascades through multiple internal endpoints, but does not detail failure modes or handling of ambiguous inputs. This adds value but is not fully exhaustive.

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 states the core purpose and when to use, second details supported types and output. No redundant or filler content.

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 clearly specifies return values for both entity types (e.g., ticker, CIK, company_name, citation URI for company). It also covers input acceptance and internal logic, making the tool complete for an agent.

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%, but the description meaningfully expands on both parameters: explains what each type resolves to (e.g., ticker, CIK, citation URI for company) and provides examples for value (e.g., names, tickers, CIKs). This goes well beyond the schema's brief 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 clearly states the tool resolves user-spoken names to canonical identifiers, with the directive "Use FIRST when you have a name but need an ID." It distinguishes from siblings by focusing on name-to-ID conversion, while other tools like compare_entities require IDs.

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 when to use it (when you have a name but need an ID) and lists supported types (company and drug) with accepted input formats. It also notes this tool replaces 2-3 manual lookups, guiding agents on efficiency.

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, openWorldHint, idempotentHint true, and destructiveHint false. The description adds behavioral details: supports pagination (via limit/offset), per-field filtering, field projection, sorting, and notes the API caps page size. 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 a single, well-structured paragraph with the main action front-loaded. Every sentence adds necessary information without 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?

Given 7 parameters, no output schema, and nested objects, the description covers usage patterns, API constraints, and prerequisites. However, it does not describe the response format or error conditions, which could benefit an AI agent.

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 detailed descriptions. The description adds value by explaining the resourceId format with an example, clarifying sort syntax, and tying filters to resource_meta for field ids. This extra context goes beyond the schema alone.

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 'Fetch records' and the resource 'any India Open Government Data resource by its resourceId'. It specifies capabilities (pagination, filtering, projection, sorting) and differentiates from sibling resource_meta by advising to use it first when field ids are unknown.

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 advises to use resource_meta first if field ids are unknown, providing clear guidance on when to use this tool vs. an alternative. It also explains how to obtain the resourceId from data.gov.in pages.

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, openWorldHint, idempotentHint, and destructiveHint as true/true/true/false, providing a strong safety profile. The description adds value by detailing the specific metadata returned (title, org, sector, last-updated, fields), though it does not discuss error handling or rate limits. 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 no wasted words. The first sentence concisely states what the tool does and what it returns. The second gives clear usage guidance. Well-structured and efficient.

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

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

Given the rich annotations (readOnly, idempotent) and full schema coverage, the description covers the main points: purpose, input parameter usage, and return content. It lacks details on error handling or pagination, but these are not critical for a metadata fetch tool. Overall, it provides sufficient context.

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

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

The input schema already has 100% coverage with descriptions for both parameters. The description adds meaning by specifying that resourceId is a UUID from the dataset's page on data.gov.in, providing context beyond the schema's description. This helps agents know where to find the parameter value.

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

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

The description clearly states it fetches schema/metadata for a data.gov.in resource by resourceId, listing title, publishing org, sector, last-updated, and fields. It distinguishes from sibling resource_data by explicitly mentioning 'before calling resource_data', making the purpose specific and differentiated.

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 explicit guidance: use this tool to discover filterable/sortable field ids before calling resource_data. This clearly states when to use it and hints at the alternative (resource_data), giving agents clear context for tool 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 provide readOnly, idempotent, non-destructive hints. Description adds that it probes each entity with ai_visibility_check, ranks results, and outputs a ranked list with score, confidence, signal density per entity. No contradictions.

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 efficient structure: what it does, how it works, when useful, and output. No unnecessary words; every sentence 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?

Despite no output schema, description explains return values (score, confidence, signal density) and process. Covers parameter roles and usage sufficiently for a complex multi-entity comparison 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 covers all 4 parameters (100% coverage). Description adds meaning: first entity treated as 'subject' for narrative, others as competitors; context disambiguates common names. This augments schema without redundancy.

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 it compares AI visibility across multiple entities side-by-side, with ranking and identification of most/least recognized. Provides a concrete use case: competitive AI-marketing audits. Distinguishes from sibling tools like ai_visibility_check (single probe) and compare_entities (generic comparison).

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 states when to use: competitive audits to compare brand visibility. Does not enumerate exclusions but the context implies for single entity use ai_visibility_check. Lacks explicit 'when not to use', but overall 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?

The description discloses domain (SEC EDGAR+XBRL), verdict types, output elements (structured form, actual value, citation, delta), and efficiency gains. Annotations already indicate safe read operations, but the description enriches with detailed behavioral context.

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

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

The description is concise, front-loaded with the action and use case, and every sentence adds value. 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 the simple input schema and no output schema, the description fully covers the tool's behavior, limitations, and return types. It is complete for an agent to use correctly.

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

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

The single parameter 'claim' has a clear description in the schema with examples. The tool description does not add new parameter semantics beyond what's in the schema. With 100% schema coverage, baseline is 3.

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

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

The description clearly states the tool's purpose: fact-checking natural-language claims against authoritative sources. It uses specific verbs like 'verify', 'confirm/refute' and specifies the resource (SEC EDGAR + XBRL). It stands out among sibling tools which are for other purposes like entity lookup or research.

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 when to use: when verifying a user's claim about factual statements, with examples. It also limits scope to company-financial claims for v1, implicitly telling when not to use (non-financial claims). However, it doesn't mention alternatives for out-of-scope claims.

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