Govtrack

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

No annotations provided, so description carries full burden. It explains the routing behavior, auto-filling arguments, and return of results. However, it does not mention any limitations, authentication needs, or potential errors for unsupported queries.

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?

Description is reasonably concise at approximately 6 sentences, with the main purpose front-loaded. It efficiently conveys the core functionality, but the list of data sources could be shortened without losing meaning.

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

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

Given the complexity and lack of output schema, the description provides examples but does not specify the return format or handling of unanswered queries. More detail on output structure would improve completeness.

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?

Only one parameter with 100% schema coverage. The description adds value by providing diverse examples of valid questions, which clarifies the expected format and scope beyond the terse schema description.

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

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

The description clearly states this tool answers natural-language questions by routing to appropriate data sources. It distinguishes itself from siblings like search_bills or get_member by being a general-purpose query tool that auto-selects the right source.

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?

Explicit guidance on when to use: 'Use when a user asks... and you don't want to figure out which Pipeworx pack/tool to call.' This contrasts with specific sibling tools and provides clear 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?

Describes internal behavior: resolves market, classifies bet type, fans out to appropriate packs, returns evidence packet and comparison. Exceeds annotations (readOnly, openWorld) by detailing the fan-out and classification logic.

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 well-structured paragraph front-loaded with action. Concise but provides necessary detail; could be slightly shorter but 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 no output schema, description thoroughly explains return value (evidence packet, market-vs-model comparison) and use cases. Context signals show low complexity but tool benefits from rich behavioral description.

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

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

Schema coverage is 100% with descriptions for both parameters (market, depth). Description does not add meaning beyond schema, as depth options are already explained in enum. Baseline 3 applies.

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

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

The description clearly states the tool researches a Polymarket bet by pulling relevant Pipeworx data in one call, with specific verb 'Research' and resource 'Polymarket bet'. It distinguishes from siblings by focusing on betting edge and classification, unlike ask_pipeworx or entity_profile.

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 use cases ('should I bet on X?', 'what does the data say...', 'is there edge?') and implies when not to use (manual pack discovery is worse). Clearly guides agent 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?

Despite no annotations, the description discloses what data is pulled for each type (SEC EDGAR/XBRL for companies, FAERS/FDA/trials for drugs) and notes it returns paired data with citation URIs. Also mentions it replaces 8–15 sequential calls, adding efficiency context.

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

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

Three sentences pack purpose, usage, type-specific behavior, and return format. Slightly verbose but well-structured and front-loads the key action.

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

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

No output schema, but description explains return format (paired data + URIs). Covers both entity types comprehensively, addressing typical user intents and data sources.

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 3. Description adds meaning: explains 'values' expects tickers/CIKs for company and drug names for drug, and enforces min/max items. This goes beyond the schema's enum and type constraints.

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 compares 2–5 companies or drugs side by side, with specific verbs like 'compare X and Y' and 'how do X, Y, Z stack up'. It distinguishes from sibling tools like entity_profile which handles single entities.

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 scenarios ('when a user says...') and explains the two types (company/drug). Lacks explicit when-not-to-use but implies through 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?

No annotations are provided, so the description must carry the full burden. It states it returns 'top-N most relevant tools with names + descriptions' and mentions default/max limit, but does not disclose any behavioral traits like caching, performance, or authentication requirements. The description is adequate but not richly 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 a single paragraph of 3 sentences, each serving a distinct purpose: stating functionality, indicating primary use case, and listing example domains. It is front-loaded with the core purpose and contains no redundant 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 tool's simplicity and full schema coverage, the description explains the query semantics, limit behavior, and return content (tool names & descriptions). It lacks explicit details on the output format structure, which could help, but the context signals show no output schema, so the description is reasonably complete.

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

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

Schema coverage is 100% with both parameters already described in the schema. The description reiterates the limit default/max and gives a query example, but adds no new semantic information beyond what the schema provides. Thus, baseline score of 3 applies.

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

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

The description uses a specific verb 'Find tools' and clearly identifies the resource. It provides concrete examples of data domains (SEC filings, FDA drugs, etc.) and distinguishes itself from sibling tools by positioning as a meta-search for discovering other tools, rather than directly querying specific data.

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

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

Explicitly tells the agent to 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear when-to-use guidance and implies alternatives (direct tool calls) by contrasting 'browse/search/discover' with targeted use.

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

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

Description details what data is returned (filings, fundamentals, patents, news, LEI) and mentions citation URIs. No annotations provided, but the description covers the read-only, multi-source aggregation behavior well. Minor omission: no mention of pagination or rate limits.

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

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

Two efficiently written sentences plus a bulleted list of outputs. Front-loaded with purpose and usage examples. Every sentence contributes 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 complexity of the tool (aggregating from multiple sources) and the absence of an output schema, the description provides sufficient detail about inputs, outputs, and usage context. It also links to a sibling tool for 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 covers both parameters with descriptions. Description adds value by specifying that 'type' only supports 'company' and that 'value' must be a ticker or CIK, not a name, with an explicit redirect to resolve_entity.

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 'Get everything about a company in one call' and lists specific data sources (SEC, USPTO, news, LEI). Distinguishes from sibling tools by positioning as a composite replacement for many individual 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?

Explicitly lists query patterns ('tell me about X', 'give me a profile', etc.) and provides a clear when-not-to-use directive: if only a name is available, resolve_entity should be called first.

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 indicates irreversible deletion ('delete'), which is appropriate. No annotations are provided, so the description carries the burden; it adequately signals the destructive nature of the operation.

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 usage hint. Front-loaded with action verb. Every word 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-param tool with no output schema, the description covers purpose, usage, and relationships. No gaps.

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 already describes the param as 'Memory key to delete' with 100% coverage. The description adds no new meaning beyond restating 'by key'.

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

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

The description clearly states the action (delete), the resource (memory), and the identifier (by key). It distinguishes from siblings 'remember' (add) and 'recall' (retrieve).

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 specific usage scenarios: stale context, task completion, clearing sensitive data. Also suggests pairing with complementary tools remember and recall.

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, description carries full burden. It details the return contents (status history, cosponsors, etc.), which is helpful for understanding what the tool does. Does not explicitly state read-only nature or error conditions, but the scope is clear.

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 sentence that front-loads purpose and enumerates returned fields. 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 one parameter and no output schema, description adequately covers return value by listing important fields. Missing details like pagination or error handling, but acceptable for a single-fetch 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% (one parameter well-described). Description adds 'numeric' but schema already says 'numeric'. No additional semantics beyond schema, baseline score applies.

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

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

Explicitly states the action (Fetch), resource (single bill), identifier (GovTrack numeric ID), and lists returned data (status history, cosponsors, etc.). Clearly distinguishes from sibling tools like search_bills.

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 use when a specific numeric bill ID is available, but no explicit guidance on when to use vs. alternatives like search_bills or get_member. Lacks 'when not to use' statements.

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 full burden. It lists the returned fields (role history, ideology score, etc.), providing transparency about output. It doesn't mention potential null values or rate limits, but the tool is a simple read.

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

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

The description is a single sentence that front-loads the purpose and follows with the return details. Every word adds value; no waste.

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 param, no output schema), the description fully informs an agent about what the tool does and returns. No additional detail is needed.

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 parameter is already described in the schema. The description's mention of 'by GovTrack person ID' confirms but adds no new meaning, earning the baseline 3.

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

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

The description clearly states 'Fetch a person record by GovTrack person ID' with specific verb and resource, and lists what it returns, distinguishing it from siblings like search_members which are for searching.

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 GovTrack person ID. It does not explicitly state when not to use or mention alternatives, but the context is clear enough for an agent with sibling tools.

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

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

With no annotations, the description carries full burden. It states the output but lacks details on authentication, rate limits, pagination, or format. Provides basic context but not comprehensive.

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 efficiently convey the action and output without unnecessary words or repetition.

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

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

Given simple inputs, the description is adequate: explains what it does and returns. Could mention that vote_id is for a specific roll-call vote, but this is already clear.

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

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

Schema coverage is 100% and the single parameter 'vote_id' is well-documented. The description adds no additional meaning beyond the schema, so baseline 3 applies.

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

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

The description clearly states the tool fetches how each member voted on a roll-call vote, specifying the output includes Yea/Nay/Present/Not Voting. It is distinct from siblings like search_votes.

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

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

The description implies usage for obtaining detailed vote breakdown for a specific roll-call vote, but does not explicitly state when to use this tool versus alternatives or provide 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 full burden. It discloses that feedback goes to the team, is read daily, affects the roadmap, and is rate-limited. It also states the tool is free and non-destructive. Minor gap: does not describe what happens after submission (e.g., no confirmation), but overall 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 concise, well-structured, and front-loaded. Every sentence adds value: purpose, use cases, constraints, and rate limits. No fluff or repetition.

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

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

For a simple input tool with no output schema, the description covers all necessary aspects: purpose, when to use, constraints, and parameter context. The agent can correctly invoke the tool based on this description alone.

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 good parameter descriptions. The description adds extra context (e.g., 'be specific', '1-2 sentences typical', '2000 chars max') but does not significantly extend the semantic understanding beyond what the schema already provides. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: sending feedback about broken, missing, or desired features to the Pipeworx team. It uses a specific verb ('tell') and resource ('Pipeworx team'), and the purpose is distinct from all sibling tools, which focus on data retrieval, entity resolution, and memory.

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 specifies when to use the tool: for bugs, feature requests, data gaps, or praise. It also provides negative guidance ('don't paste the end-user's prompt') and mentions rate limits (5 per identifier per day) and that the call is free and doesn't count against quota, giving clear usage boundaries.

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

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

Annotations already declare the tool as read-only and non-destructive. The description adds useful behavioral context: it walks child markets, extracts dates, sorts, and reports violations. 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 well-structured and informative, but slightly long. It efficiently explains the logic and output without 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 complexity of arbitrage detection and the single parameter, the description fully explains the tool's behavior, input requirements, and output structure. No output schema exists, but the description lists output fields (market_a, market_b, gap_pp, suggested_trade), which is 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?

Schema describes the parameter briefly; the description adds meaningful context (e.g., 'walks child markets, extracts dates/thresholds'). With 100% schema coverage, baseline is 3, but the description enriches understanding.

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 purpose: finding arbitrage opportunities via monotonicity violations. It uses specific verbs and resource, and distinguishes itself from sibling tools like bet_research and polymarket_edges by focusing on monotonicity within a single event.

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

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

Provides clear context on when to use (events with multiple 'by date' or 'by threshold' markets) and a concrete example. However, it does not explicitly state when not to use or mention alternative tools, such as when checking cross-event arbitrage.

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 readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral detail: it scans top markets, groups by asset, fetches price history once, computes model probability, and ranks by edge. It also reveals the underlying model (lognormal from FRED + coinpaprika) and return format (top N with trade direction). 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 a single paragraph that front-loads the main action. Every sentence contributes useful information, though it could be slightly more concise by omitting model details (e.g., 'lognormal model from FRED + live coinpaprika price'). Overall, it is well-structured and not overly verbose.

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 (multi-step analysis) and absence of an output schema, the description provides sufficient context: it explains the algorithm steps and return format (top N with edge magnitude and direction). The parameter descriptions and annotations cover the remaining needs. A minor gap is the lack of detail on the exact output fields, but the high-level description is adequate 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?

All three parameters (limit, window, min_edge_pp) have descriptions in the input schema (100% coverage), so the baseline is 3. The description does not add significant extra meaning beyond what the schema already provides, e.g., it mentions default values but those are already in 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 tool scans high-volume Polymarket markets, identifies discrepancies between Pipeworx data and market prices, and returns ranked edges with trade suggestions. It specifies the scope (crypto-price bets, lognormal model) and distinguishes itself from siblings like polymarket_arbitrage by its specific use case.

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 the tool is built for the 'what should I bet on today' question, implying its use for discovering opportunities without manual browsing. It does not, however, explicitly state when not to use it or compare to alternatives like bet_research, but the context is clear enough for typical 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?

No annotations exist; the description discloses scoping (by identifier) and the behavior when omitting the key. It does not explicitly state it is read-only/non-destructive, but the retrieval nature is clear.

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 informative sentences with no fluff – front-loaded with the main action, then usage context, then scope and pairing.

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 16 sibling tools, the description clearly differentiates recall from remember/forget. No output schema is present, but the return value (value or list of keys) is implied adequately.

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

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

Schema coverage is 100%; the description adds value by explaining the effect of omitting the key (list all keys) and the purpose of the key 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 states 'Retrieve a value previously saved via remember, or list all saved keys' – a clear verb+resource scope that distinguishes it from the sibling tools 'remember' and 'forget'.

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 to look up context the agent stored earlier' and 'Pair with remember to save, forget to delete', providing clear when-to-use and 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. Discloses fan-out to three sources in parallel, return format (structured changes, count, URIs), and parameter options. Lacks edge case descriptions like empty results or errors.

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 that front-loads purpose with a question. Every sentence adds meaningful detail. Could be slightly more concise but avoids 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?

No output schema, so description explains return shape (structured changes, count, URIs). Covers all three required parameters and their semantics. Adequate for a tool with moderate complexity and no nested objects.

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 value by explaining accepted formats for 'since' (ISO vs relative) and recommending values, and clarifying 'value' can be ticker or CIK. This exceeds what schema alone provides.

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

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

Description clearly states the verb and resource: retrieving recent changes for a company. Provides example queries that directly address user intent. Differentiates from siblings like entity_profile by detailing fan-out to multiple data sources.

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

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

Explicitly states when to use with common query patterns ('use when a user asks...'). Recommends default 'since' values for monitoring. Does not list alternatives or exclusions, but usage context is clear.

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

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

Despite no annotations, the description reveals key behaviors: scoped by identifier, authenticated users get persistent memory, anonymous sessions retain memory for 24 hours. This level of detail helps the agent understand storage semantics without needing annotations.

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

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

Three sentences that are efficient and front-loaded: first sentence states purpose, second gives usage guidance, third explains behavior and tool pairing. No superfluous information.

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

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

For a two-parameter tool with no output schema, the description covers purpose, usage, storage behavior, persistence, and links to sibling tools. It is complete enough for an agent to use correctly without additional 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?

Schema already includes descriptions for both parameters (key and value). The description adds value by providing naming conventions for keys (e.g., 'subject_property', 'target_ticker') and clarifying that value is 'any text.' This goes beyond the schema's basic 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's purpose: 'Save data the agent will need to reuse later.' It specifies the verb (save), resource (data/values), and scope (across conversations/sessions). It distinguishes from sibling tools like recall and forget by mentioning them explicitly.

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 excellent guidance on when to use: 'when you discover something worth carrying forward' and gives concrete examples. It pairs with recall and forget. While it doesn't explicitly state when not to use, the context is clear enough for an AI agent to make decisions.

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 implies a read-only lookup and mentions return format (IDs plus pipeworx:// URIs), but does not explicitly state safety, authentication needs, or error behavior. Adequate but could be more 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?

Five concise sentences with no redundancy. Front-loaded with purpose, followed by when-to-use, examples, return details, and best practice. 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?

Covers purpose, usage, parameters, and return format. Lacks error handling or limitations (e.g., ambiguous inputs), but given tool simplicity, this is nearly complete. Could mention that it handles both company and drug types in one call.

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

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

Schema description coverage is 100%, and the description adds significant context: examples of valid values (tickers, CIKs, drug names), explanation of how input format varies by type, and mapping to output IDs. This goes well beyond the schema's basic type constraints.

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 looks up canonical identifiers for companies or drugs, specifies return types (CIK, ticker, RxCUI, LEI), and includes concrete examples (Apple → AAPL, Ozempic → RxCUI). It differentiates from siblings by mentioning it replaces 2-3 lookup calls and should precede other 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?

Provides explicit when-to-use: 'Use when a user mentions a name and you need the CIK... or LEI' and 'Use this BEFORE calling other tools that need official identifiers.' While it doesn't list alternatives or when not to use, the guidance is clear and actionable.

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

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

No annotations provided, so description carries full burden. It discloses output fields but lacks mention of side effects (likely none), authentication needs, rate limits, or pagination behavior beyond what schema provides.

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 concise sentence (~20 words) that front-loads action and key filters. No waste, all parts contribute to understanding.

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 8 parameters, no output schema, and no annotations, the description covers basic filters and output but lacks guidance on default behavior (e.g., default limit), combination of filters, and differentiation from sibling tools. Could be more comprehensive.

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

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

Schema coverage is 100% so baseline is 3. Description adds value for 'congress' parameter with year example, but is redundant for 'q', and omits limit, offset, order_by, bill_type. Overall marginal improvement over 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 the verb 'search' and resource 'federal congressional bills', lists key filters (congress, current_status, sponsor, free-text query) and output fields. It distinguishes from siblings like 'get_bill' and 'search_members'.

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 searching/filtering bills, but no explicit when-to-use vs alternatives (e.g., 'get_bill'), no exclusions, and no guidance on combining filters or common 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?

No annotations exist. The description does not disclose any behavioral traits beyond what the schema provides. It lacks details on authorization, pagination behavior, or error handling.

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. The first sentence states purpose, the second lists key filters. 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 8 parameters and no output schema, the description is too brief. It fails to explain the return structure or how filters interact, leaving the agent with incomplete 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?

Schema coverage is 100%, so baseline is 3. The description repeats some parameter names but adds no new meaning beyond the schema's 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 'Search current and historical congressional members' with specific filter options. It distinguishes itself from sibling search tools (search_bills, search_votes) by focusing on members, but not explicitly.

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

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

The description provides a list of filters (role_type, state, party, current) implying usage scenarios. However, it offers no guidance on when not to use or compare to alternatives like search_bills.

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 empty annotations, the description carries the burden but only discloses a read-like operation ('Search') and return fields. No mention of side effects, auth, or rate limits.

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

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

The description is extremely concise, using two short sentences to convey purpose, filters, and return fields. 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 no output schema, the description adequately explains the return data (vote ID, motion, result, totals). It covers main filters but omits ordering and pagination details (though schema covers them).

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 adds value by listing example categories (passage, nomination, amendment) that are not in the schema description, aiding the agent.

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 searches roll-call votes and lists filters, distinguishing from siblings like search_bills and search_members. However, it does not explicitly differentiate from the sibling get_vote_detail.

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 via available filters but does not specify when to use this tool versus alternatives (e.g., get_vote_detail for a single vote) or when not to use it.

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

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

Describes return format (verdict, extracted structured form, actual value with citation) and notes it replaces multiple steps; lacks details on data freshness or error handling, but no annotations exist to contradict.

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 with no wasted words; front-loads purpose and usage, then scope and return 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?

Explains return value well despite no output schema; mentions data source (SEC EDGAR + XBRL). Could add edge case handling but overall 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?

Adds context beyond the schema with examples of natural-language claims, enhancing understanding despite full schema coverage.

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

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

The description clearly states the tool fact-checks factual claims against authoritative sources, specifically for company-financial claims, differentiating it from general Q&A siblings like ask_pipeworx.

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 with examples and scope, but does not explicitly state when not to use or mention alternatives.

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