simplefunctions

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it implies a write operation ('Record a new position'), it lacks details on permissions, side effects, error handling, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is extremely concise and front-loaded, consisting of just two sentences that directly state the purpose and usage context. Every word earns its place, with no redundant or unnecessary information, making it efficient and easy to parse.

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

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

Given the tool's complexity (a write operation with 9 parameters, 7 required), no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like what happens on success/failure, authentication needs (implied by 'apiKey' but not explained), or how it integrates with sibling tools, leaving significant gaps for 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 description coverage is 100%, so the input schema already documents all parameters thoroughly. The description doesn't add any additional meaning or context beyond what the schema provides (e.g., it doesn't explain relationships between parameters like 'thesisId' and 'externalMarketId'). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with a specific verb ('Record') and resource ('new position in a thesis for tracking'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_position' or 'close_position', which would require more specific context about when to use each.

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 implied usage guidelines by stating 'Use after an intent fills or a manual trade,' which gives some context for when to invoke this tool. However, it doesn't explicitly mention alternatives (e.g., when to use 'update_position' instead) or exclusions, leaving room for ambiguity compared to 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 provided, the description carries the full burden. It discloses the 'append-only' behavioral trait, which is valuable context beyond the basic 'merge' action. However, it doesn't mention permissions, side effects, rate limits, or what happens on failure. The 'Advanced' label hints at complexity but lacks specifics.

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, efficient sentence with zero waste. It's front-loaded with the core action and includes a qualifier ('append-only') that adds necessary context without verbosity. Every word earns its place.

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

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

For a mutation tool with no annotations and no output schema, the description is minimal but covers the core purpose. It lacks details on permissions, error handling, or return values, which are important for an 'Advanced' operation. The 100% schema coverage helps, but behavioral context is incomplete.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description doesn't add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain how 'dryRun' interacts with merging). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the action ('merge suggested causal tree nodes from evaluations') and resource ('into the tree'), with the qualifier 'append-only' indicating a specific type of merge. It distinguishes from siblings like 'update_nodes' by focusing on merging from evaluations rather than general updates, though it doesn't explicitly name alternatives.

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

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

The description implies usage when there are 'suggested causal tree nodes from evaluations' to be merged, but doesn't specify when to use this versus alternatives like 'update_nodes' or 'update_thesis'. No explicit when-not or prerequisite guidance is provided, leaving usage context somewhat implied.

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

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

With no annotations, the description adds only the cost hint ('Cheaper'), but does not disclose rate limits, error behavior, or response handling. It meets minimum disclosure but is 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?

Single, front-loaded sentence with no wasted words. Every part 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 2-param tool with no output schema, the description covers the purpose and cost advantage but omits return format, limits, and error scenarios. Adequate but not 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%, so parameters are already described. The description adds no extra meaning beyond 'by ticker list', which matches the schema's 'Comma-separated tickers'. 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 uses a clear verb ('Fetch') and resource ('markets'), and explicitly contrasts with a sibling ('get_market_detail'), distinguishing the tool's batch nature.

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

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

It states when to use this tool ('cheaper than calling get_market_detail in a loop'), providing a clear usage context, though it does not mention when not to use it or other 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context: 'No auth required' clarifies access requirements, and 'Filter by category, search, or sort by popularity' hints at functionality beyond basic listing. It doesn't cover rate limits or response format, but provides useful operational details.

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

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

The description is two sentences with zero waste: the first states the core purpose and auth requirement, the second lists capabilities. It is appropriately sized and front-loaded, with every sentence earning its place.

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

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

For a read-only tool with 3 parameters and 100% schema coverage but no output schema, the description is reasonably complete. It covers purpose, auth, and capabilities, though it doesn't explain return values or pagination. Given the tool's moderate complexity, it provides sufficient context for an agent to use it effectively.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters (q, sort, category). The description mentions filtering and sorting but adds no syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the verb ('browse') and resource ('public skills from the community'), making the purpose specific and unambiguous. It distinguishes this tool from siblings like 'list_skills' or 'explore_public' by emphasizing the public/community aspect and browsing functionality.

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

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

The description provides clear context for when to use this tool ('browse public skills from the community') and mentions filtering/sorting capabilities. However, it does not explicitly state when not to use it or name alternatives among siblings (e.g., 'list_skills' might be for private skills), leaving some ambiguity.

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

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

No annotations are provided, so the description carries full burden. It mentions 'Stops trigger evaluation and prevents execution', which adds some behavioral context about halting processes. However, it lacks details on permissions, reversibility, side effects, or response format, leaving significant gaps for a mutation tool.

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

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

The description is extremely concise with two short sentences that directly state the tool's purpose and effect. Every word contributes meaning, with no wasted text, making it front-loaded 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?

For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on success/failure outcomes, error conditions, or broader system impact, which are critical for an agent to use this tool effectively in 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 description coverage is 100%, with both parameters ('apiKey', 'intentId') well-documented in the schema. The description adds no additional parameter details beyond what the schema provides, so it meets the baseline of 3 without compensating for any gaps.

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 ('Cancel') and resource ('an active intent'), specifying what the tool does. It distinguishes from siblings like 'create_intent' or 'list_intents' by focusing on termination rather than creation or listing.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an active intent) or compare to other tools like 'close_position' or 'update_strategy', leaving usage context unclear.

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

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

No annotations are provided, so the description carries full burden. It states 'Delete,' implying a destructive mutation, but doesn't disclose behavioral traits like whether deletion is permanent, requires specific permissions, has side effects on related data, or returns confirmation. This leaves significant gaps in understanding the tool's impact.

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, direct sentence with zero wasted words, efficiently conveying the core action and target. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly without unnecessary detail.

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

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

Given the tool's complexity as a destructive operation with no annotations and no output schema, the description is incomplete. It fails to address critical aspects like return values, error conditions, or confirmation of deletion, leaving the agent with insufficient information for reliable invocation.

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

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

Schema description coverage is 100%, with clear parameter descriptions in the input schema (e.g., 'Thesis ID,' 'Position ID,' 'SimpleFunctions API key'). The description adds no additional semantic context beyond what the schema provides, so it meets the baseline for adequate but not enhanced parameter 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 action ('Delete') and target resource ('a position record from a thesis'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'update_position' or 'add_position', which would require more specific context about what distinguishes deletion from modification or creation.

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

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

No guidance is provided on when to use this tool versus alternatives like 'update_position' or other position-related operations. The description lacks context about prerequisites, such as ensuring the position exists or isn't actively in use, leaving the agent without usage direction.

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

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

With no annotations provided, the description carries full burden. It mentions the tool configures settings but doesn't disclose behavioral traits like whether changes are immediate, reversible, require specific permissions, or have side effects. The description adds some context about volatility/budget scenarios but lacks details about the mutation's impact, error conditions, 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 appropriately sized with two sentences. The first sentence front-loads the purpose and lists key parameters efficiently. The second sentence provides usage guidance. There's minimal waste, though the parameter listing could be slightly more structured.

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

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

For a configuration/mutation tool with 7 parameters, no annotations, and no output schema, the description is adequate but has gaps. It covers what the tool does and when to use it but lacks details about the mutation's behavior, response format, error handling, or prerequisites. The schema provides parameter documentation, but the description doesn't compensate for missing behavioral 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 description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description lists parameter categories (news scan interval, X scan interval, etc.) but doesn't add meaningful semantic context beyond what's in the schema descriptions. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the tool configures the '24/7 heartbeat engine' with specific configuration parameters (news scan interval, X scan interval, LLM model tier, monthly budget, pause/resume). It specifies the verb 'configure' and resource 'heartbeat engine' but doesn't explicitly differentiate from sibling tools like 'get_heartbeat_status' or 'monitor_the_situation'.

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 usage context: 'Agent can speed up monitoring during high volatility or slow down to save budget.' This gives practical guidance on when to adjust settings. However, it doesn't explicitly state when NOT to use this tool or mention alternatives among the many sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that intents are evaluated and executed via user's keys, hinting at external dependencies and potential financial actions, but lacks details on permissions, rate limits, error handling, or what happens upon execution (e.g., order confirmation). This leaves gaps for a tool with significant real-world impact.

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 highly concise and front-loaded, using just two sentences that efficiently convey the core purpose and mechanism without any wasted words. Every sentence earns its place by defining the tool's role and execution process clearly.

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 (15 parameters, financial trading context) and lack of annotations or output schema, the description is incomplete. It adequately explains the high-level purpose but misses critical details like return values, error cases, or behavioral nuances needed for safe use in a trading environment, leaving room for improvement.

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

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

Schema description coverage is 100%, so the input schema already documents all 15 parameters thoroughly. The description adds minimal value by implying parameters like 'buy X' (action/market), 'condition Y' (trigger), and 'expire at Z' (expireAt), but does not provide additional semantics beyond what the schema offers, such as usage examples or constraints not in 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 with specific verbs ('declare an execution intent') and resources ('buy X when condition Y, expire at Z'), explicitly distinguishing it from siblings by noting it's 'the single gateway for all order execution.' This goes beyond just restating the name to explain its unique role in the system.

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 that this tool is for declaring intents that are evaluated and executed by a local runtime daemon, implying it should be used for automated trading setups. However, it does not explicitly state when not to use it or name specific alternatives among the many sibling tools, such as 'add_position' or 'update_position,' which might handle similar trading actions.

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

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

With no annotations provided, the description carries full burden but only states the basic function. It doesn't disclose behavioral traits such as permissions needed (e.g., API key usage), whether creation is reversible, rate limits, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.

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, efficient sentence that front-loads the core purpose. Every word earns its place without redundancy, making it easy to parse quickly.

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

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

For a creation tool with 10 parameters, no annotations, and no output schema, the description is insufficient. It lacks context on usage scenarios, error handling, or what the tool returns (e.g., a skill ID). This leaves significant gaps for an agent to operate effectively.

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

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

Schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't clarify relationships between parameters like 'trigger' and 'name'). Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the action ('Create') and resource ('custom agent skill'), specifying it's a reusable prompt/workflow triggered via slash command. It distinguishes from siblings like 'fork_skill' (which duplicates) or 'list_skills' (which retrieves).

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

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

No explicit guidance on when to use this tool versus alternatives like 'fork_skill' (for duplicating) or 'publish_skill' (for making public). The description implies usage for initial creation but lacks context on prerequisites or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context about the 'heartbeat engine' checking conditions every 15 minutes and executing when met, which reveals automation behavior. However, it doesn't cover important aspects like authentication needs (apiKey is documented in schema but not described in behavior), rate limits, error handling, or what happens on execution failure.

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 appropriately sized with two sentences that efficiently convey the core functionality. The first sentence establishes the purpose, and the second adds important behavioral context about the heartbeat engine. There's minimal waste, though it could be slightly more structured for clarity.

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

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

For a complex 14-parameter tool with no annotations and no output schema, the description provides adequate but incomplete context. It covers the automation aspect well but doesn't address important considerations like what the tool returns, error conditions, or how it interacts with other trading tools. The description compensates somewhat for the lack of structured metadata but leaves 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 description coverage is 100%, so the schema already documents all 14 parameters thoroughly. The description mentions key parameters like 'entry price, stop loss, take profit, and LLM-evaluated soft conditions' but doesn't add meaningful semantic context beyond what the schema provides. It establishes the purpose but doesn't clarify parameter relationships or usage nuances.

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 with specific verbs ('Set up automated trading') and resources ('define entry price, stop loss, take profit, and LLM-evaluated soft conditions'), distinguishing it from siblings like 'create_intent' or 'update_strategy' by focusing on automated trading strategy creation with heartbeat monitoring.

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

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

The description implies usage context ('automated trading', 'heartbeat engine checks conditions every 15 min') but doesn't explicitly state when to use this tool versus alternatives like 'create_intent' or 'update_strategy'. It provides some operational context but lacks explicit guidance on prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Builds a causal tree and scans for mispriced contracts', which hints at computational behavior, but it lacks critical details like whether this is a read-only or mutating operation, what permissions or API keys are required (though the schema covers the apiKey parameter), rate limits, or what the output looks like. For a creation tool with zero annotation coverage, this is insufficient.

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, efficient sentence that front-loads the core purpose and adds implementation details without redundancy. Every word earns its place, making it highly concise and well-structured.

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

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

Given the complexity of creating a prediction market thesis with no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., mutation effects, error handling), output details, and usage guidelines, leaving significant gaps for the agent to navigate.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (sync, apiKey, thesis) with descriptions. The description doesn't add any meaning beyond what the schema provides, such as explaining the relationship between parameters or usage examples. The baseline score of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the action ('Create a new prediction market thesis') and the resource ('thesis'), and it adds implementation details about building a causal tree and scanning for mispriced contracts. However, it doesn't explicitly differentiate this tool from sibling tools like 'create_intent', 'create_skill', or 'create_strategy', which all involve creation operations in the same domain.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, compare it to similar tools like 'create_intent' or 'create_skill', or specify scenarios where it's appropriate. The agent must infer usage from the purpose alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: 'No auth, no Firecrawl needed' indicates accessibility and integration simplicity, and 'Demo/trial entry point' hints at potential limitations or trial nature. However, it lacks details on rate limits, error handling, or what 'divergence analysis' entails in practice, leaving gaps for a tool with no output schema.

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

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

The description is concise and front-loaded, starting with the core functionality. Each sentence adds value: the first explains the tool's purpose, the second specifies input/output, and the third provides contextual details. However, the phrase 'Demo/trial entry point' could be more precise, and the structure slightly mixes operational details 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?

Given the complexity of cross-referencing text with prediction markets and no output schema, the description is moderately complete. It covers the tool's purpose, input requirements, and some behavioral context (e.g., no auth needed), but lacks details on output format, error cases, or how 'divergence analysis' is presented. For a tool with 4 parameters and no annotations, more completeness would be beneficial.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, mentioning 'Paste content + topics' which aligns with the required parameters but doesn't provide additional syntax or format details. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter 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 tool's purpose: 'Cross-reference any text with thousands of prediction market contracts' and 'get divergence analysis: where sentiment disagrees with market prices.' It specifies the verb ('cross-reference', 'get divergence analysis') and resource ('text', 'prediction market contracts'), though it doesn't explicitly differentiate from sibling tools like 'scan_markets' or 'screen_markets' which might have overlapping functionality.

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

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

The description implies usage context by mentioning 'Demo/trial entry point' and 'No auth, no Firecrawl needed,' suggesting it's for initial exploration or testing. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'scan_markets' or 'query', nor does it specify prerequisites or exclusions beyond the implied trial 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 carries the full burden. It discloses that 'No auth required' and implies read-only behavior ('Browse'), but lacks details on rate limits, pagination for listing, or error handling. This is adequate but has gaps for a tool with no 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 zero waste: it states the purpose, auth requirement, and parameter usage efficiently. Every sentence adds value, and it's front-loaded with key 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 no annotations, no output schema, and a simple input schema, the description is moderately complete. It covers purpose, auth, and parameter usage but lacks details on return values, error cases, or behavioral constraints like rate limits. This is adequate but not fully 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?

The schema description coverage is 100%, so the schema already documents the 'slug' parameter. The description adds minimal value by restating the parameter's purpose ('Pass a slug to get details, or omit to list all'), which aligns with the schema but doesn't provide additional semantics like format examples. Baseline 3 is appropriate here.

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

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

The description clearly states the action ('Browse') and resource ('public theses from other users'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_theses' or 'browse_public_skills', which would require a 5.

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: 'Pass a slug to get details, or omit to list all.' It also mentions 'No auth required,' which is helpful. However, it doesn't specify when to use this tool over alternatives like 'list_theses' or 'browse_public_skills', preventing a score of 5.

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

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

No annotations are provided, so the description must carry the burden. It states the tool is for browsing (read-only), which is appropriate, but lacks details on auth, rate limits, or other behavioral traits. It is adequate but not rich.

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

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

The description is two sentences, front-loaded with the key action, and contains no waste. Every word serves a 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 simple browse tool with one optional parameter and no output schema, the description is mostly sufficient. However, it fails to mention what the tool returns (e.g., a list of thesis summaries or a full thesis object), which would be helpful.

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

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

The schema has one parameter 'slug' with a clear description. The tool description essentially repeats that ('Pass slug to get one, omit to list'). With high schema coverage (100%), baseline is 3, and the description adds no significant new 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?

The description clearly states the action ('Browse'), the resource ('public theses'), and the behavior (list or get one by slug). It also distinguishes itself from siblings by noting it's an alias of explore_public.

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 explains how to use the tool: pass slug to get one thesis, omit to list all. It implies it's an alias of explore_public, but does not provide explicit alternatives or when-not-to-use guidance.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the operation ('fork') which implies a copy/create action, but doesn't describe what happens during forking (e.g., whether it creates an editable copy, maintains links to original, includes dependencies). No information about permissions needed, rate limits, error conditions, or what the forked skill inherits. The description is minimal and leaves significant behavioral aspects unspecified.

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 at just two sentences, with zero wasted words. It's front-loaded with the core purpose, followed by a brief parameter guidance. Every sentence earns its place by providing essential information about the tool's function and parameter expectations.

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

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

Given no annotations and no output schema, the description is incomplete for a mutation tool. While concise, it lacks critical information about what the fork operation actually does behaviorally, what permissions are required, what the response contains, or how the forked skill relates to the original. For a tool that presumably creates a copy of someone else's work, more context about the operation's implications would be valuable.

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

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

Schema description coverage is 100%, so both parameters are documented in the schema. The description adds minimal value beyond the schema: it mentions 'No slug needed' which clarifies what's NOT required, and 'just the skill ID' reinforces the skillId parameter's purpose. However, it doesn't provide additional context about parameter relationships, validation rules, or usage patterns that aren't already in 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 action ('Fork') and resource ('a public skill into your collection'), providing a specific verb+resource combination. It distinguishes from siblings like 'create_skill' by specifying it's for forking existing public skills rather than creating new ones from scratch. However, it doesn't explicitly differentiate from 'fork_thesis' which is a similar operation on a different resource type.

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

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

The description implies usage context by specifying 'public skill' and 'into your collection,' suggesting this is for copying shared skills to personal use. It mentions 'No slug needed' which provides some guidance about parameter requirements. However, it doesn't explicitly state when to use this versus alternatives like 'create_skill' or 'browse_public_skills,' nor does it provide exclusion criteria or prerequisites beyond having the skill ID.

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

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

With no annotations provided, the description carries full burden. It mentions copying content and running 'formation to scan for fresh edges,' which hints at post-fork automation, but fails to disclose critical behavioral traits like authentication needs (implied by apiKey), rate limits, side effects, or what 'formation' entails. This leaves significant gaps for a mutation tool.

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

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

The description is concise and front-loaded with the main action, using three sentences that each add value: forking, copying content, and post-fork automation. There is no wasted text, though it could be slightly more structured for clarity.

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

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It misses details on authentication (only implied by apiKey), error handling, what 'formation' does, and the return value. Given the complexity and lack of structured data, more context 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 description coverage is 100%, so the schema already documents both parameters (apiKey and idOrSlug). The description adds no additional meaning about parameters beyond implying 'idOrSlug' refers to a public thesis, which is minimal value. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the action ('Fork a public thesis into your collection') and specifies what gets copied ('thesis statement and causal tree'), which distinguishes it from generic creation tools. However, it doesn't explicitly differentiate from sibling tools like 'fork_skill' or 'create_thesis' beyond mentioning 'public thesis'.

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 forking public theses but provides no guidance on when to use this versus alternatives like 'create_thesis' or 'fork_skill', nor does it mention prerequisites or exclusions. It lacks explicit when/when-not instructions.

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

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

No annotations are provided, so the description must disclose behavior. It only says it's a 'playbook' with workflows, but doesn't state whether it's read-only, has side effects, or requires authentication. Inadequate given the lack of annotations.

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

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

Two lean sentences, front-loaded with purpose. Efficient but could include a bit more structure without bloat.

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

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

With no output schema or annotations, the description should cover return format, example usage, or cross-reference siblings. It only gives high-level purpose and usage scenario, leaving gaps 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%, so baseline of 3. The description mentions intents (matching the enum) but adds no new meaning beyond what schema already provides for either parameter.

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

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

The description clearly states it provides a runtime playbook with workflows for specific intents (query, monitor, integrate). It distinguishes itself from generic 'get_' tools by specifying its role for agent onboarding.

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 when an agent is lost or needs onboarding', giving clear context. Does not mention alternatives or when not to use, but the guidance is direct.

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

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

With no annotations provided, the description carries full burden. It discloses return fields but does not state whether the tool is read-only, requires authentication, has rate limits, or any side effects. The term 'pre-computed' implies safety but is not explicit.

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

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

Two concise sentences with no superfluous text. Purpose and output are front-loaded, making it easy for an AI agent to quickly understand the tool.

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

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

For a simple tool with one parameter and no output schema, the description sufficiently explains what is returned. However, it lacks context about data availability (e.g., when answer cards exist) and does not clarify how this differs from similar tools.

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

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

Schema coverage is 100% and documents the slug parameter adequately. Description does not add any additional parameter information beyond what the schema provides, so baseline 3 is appropriate.

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

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

Description clearly states the tool retrieves a pre-computed answer card for a probability question, including specific return fields (probability, confidence, citations). This differentiates it from sibling get_* tools like get_forecast or get_opinion by focusing on answer cards for probability questions.

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

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

No explicit guidance on when to use this tool versus alternatives. While it mentions the data powers /answer/{slug}, it doesn't indicate when to prefer this over related tools (e.g., get_forecast) or any prerequisites or constraints.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Advanced:' which might imply complexity or additional requirements, but doesn't explain what that entails (e.g., rate limits, authentication needs, or data freshness). It also doesn't describe the return format (e.g., numeric balance, structured portfolio data) or potential errors. For a financial tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is brief with two phrases, but 'Advanced:' is vague and doesn't earn its place by adding useful information—it could be omitted without loss. The core purpose is stated efficiently, but the structure isn't front-loaded with the most critical details (e.g., it doesn't immediately clarify this is a read-only tool for account data). It's concise but could be more effectively structured.

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

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

Given the complexity of a financial tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., balance in dollars, portfolio breakdown), behavioral aspects like authentication requirements or rate limits, or how it fits with sibling tools. For a tool that likely provides critical account information, this leaves too much unspecified for reliable agent use.

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

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

The input schema has 100% description coverage for its single parameter (apiKey), detailing it as a 'SimpleFunctions API key' with a URL for acquisition. The description adds no parameter-specific information beyond what the schema provides, such as how the apiKey relates to the Kalshi account or any additional context. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter 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 states the tool retrieves 'Kalshi account balance and portfolio value', which specifies the resource (account/portfolio) and the action (get/retrieve). However, it's prefixed with 'Advanced:' which adds ambiguity rather than clarity, and it doesn't distinguish this from potential sibling tools like 'get_fills' or 'get_settlements' that might also relate to account data. The purpose is clear but not optimally specific.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an API key for authentication), context for usage (e.g., checking account status before trading), or exclusions (e.g., not for real-time market data). With many sibling tools present, this lack of differentiation leaves the agent to infer usage from the name alone.

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

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

With no annotations, the description carries the burden of disclosure. It implies a read-only operation ('briefing') and lists outputs, but does not explicitly state side effects, permissions, or rate limits. It is adequate but not thorough.

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

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

The description is short (two sentences) and front-loaded with the main purpose. It avoids redundancy but could be slightly more structured. However, it is concise enough for an agent.

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

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

Given no output schema and two parameters with full schema coverage, the description lists the output components (narrative, markets, moves, dates) which helps. However, it omits return format, error handling, and defaults, leaving 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 description coverage is 100%, so baseline is 3. The description adds minimal value beyond 'topic keyword' and 'lookback window', merely restating them in context. No additional semantics are provided.

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

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

The description clearly states it's a 'topic-scoped briefing' with specific components (narrative, markets, moves, dates), distinguishing it from sibling tools like get_market_detail or get_calendar. However, it could be more explicit about how it differs from other get_* tools.

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

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

The description provides no guidance on when to use this tool vs alternatives. It mentions 'reusable as a callable /briefing card' but does not specify scenarios or prerequisites, leaving the agent uncertain about 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 provided. Description discloses output fields but omits details like default lookahead (30 days as per schema) or any authentication/rate limit requirements. Includes relevant examples, but lacks comprehensive behavioral traits.

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

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

Two sentences, front-loaded with purpose, no wasted words. Efficient and to the point.

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 outlines return fields (date, topic, tickers). With two optional parameters and clear context among many siblings, the description is mostly complete for a 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%, so baseline 3 is appropriate. Description adds minimal value beyond schema by giving example categories but does not clarify parameter formats or 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 retrieves 'upcoming dated events that drive prediction markets' with specific examples (FOMC, CPI, election dates, sports finals) and output fields (date, topic, linked tickers). This distinguishes it from other get_ tools on the server.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies it's for market-relevant events, but does not state when not to use it or compare with other tools like get_schedule.

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

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

No annotations are provided, so the description must fully convey behavioral traits. It names outputs (e.g., drift alerts) but does not explain behaviors like data freshness, authentication requirements, or operational constraints. The description is insufficient for an agent to understand side effects or 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 two sentences, listing key outputs and measurement context. It is concise without superfluous words. However, the first sentence is a comma-separated list which slightly reduces readability. Still efficient overall.

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

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

Given the tool has two parameters, no output schema, and no annotations, the description is minimally complete. It covers what the tool returns but omits details like output format, interpretation of drift alerts, or examples. Could be improved with more 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?

Both parameters (period and category) are fully described in the input schema, achieving 100% coverage. The description adds no extra semantic nuance beyond the schema. Baseline score of 3 is appropriate as the schema already provides adequate 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?

The description clearly states the tool returns calibration data including Brier scores, hit rates, category breakdowns, and drift alerts. It specifies the resource (calibration) and that measurements are against resolved markets. However, it could be more explicit about what exactly is being calibrated (e.g., forecast probabilities).

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or specific contexts. While the purpose is clear, an agent lacks cues for appropriate invocation relative to 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?

No annotations are provided, so the description carries the full burden. It states the tool returns change events, implying a read operation, but does not disclose other behaviors like authentication, rate limits, or pagination. The description is adequate but lacks 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 two sentences (17 words), front-loaded with key information, and wastes no words. It achieves efficiency without sacrificing clarity.

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

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

For a simple tool with 3 parameters and no output schema, the description covers the essential aspects: purpose, relevant event types, and usage context. It does not explain return format, but that is acceptable given the lack of output schema.

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

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

Input schema has 100% description coverage, so the description adds limited additional value. It mentions the event types (new_contract, price_move, removed_contract) which align with the type parameter, but does not provide further semantic enrichment 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 it retrieves market change events (new contracts, price moves, removed contracts) since a timestamp. It does not explicitly differentiate from sibling tools like get_changes_delta, but it provides enough context to understand its purpose.

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

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

The description mentions it is used by the live feed and agent context refreshers, giving context for when to use it. However, it does not provide explicit alternatives or when-not-to-use guidance, leaving room for ambiguity.

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 present, so description carries full burden. It indicates a read operation returning evolution details but does not disclose side effects, permissions beyond the API key, or any limitations. Adequate but not 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?

Single sentence, front-loaded with the main action. Every word contributes value; no wasted text.

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 sufficiently explains return value (signals, edges, confidence moves). Missing pagination or ordering details, but acceptable for a delta 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%, baseline 3. Description adds context by linking 'since' to the timestamp and 'thesisId' to the thesis, but no extra details beyond 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 retrieves a per-thesis change delta since a timestamp. It specifies the resource (thesis) and the action (get delta), and distinguishes from the sibling 'get_changes' by adding 'delta' and listing what evolved.

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 tracking changes over time but does not explicitly mention when not to use it or suggest alternatives like 'get_changes'. No guidance on selection between similar tools.

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

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

No annotations provided, and the description does not disclose any behavioral traits (e.g., read-only, rate limits, or side effects). 'Get' implies read-only but is not explicit.

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

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

Single sentence, no fluff, directly conveys the tool's 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 simple lookup by ID with one parameter, the description is sufficient. No output schema exists, but description doesn't need to detail return values. Minimal but 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 description coverage is 100% with 'Bioguide ID' for the parameter. 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?

Description clearly states 'Get a single Congress member by bioguide ID', specifying the action (get) and the resource (Congress member), and distinguishes from sibling 'list_congress_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?

No guidance on when to use this tool versus alternatives like 'list_congress_members'. No explicit when-to-use or when-not-to-use 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 provided, so description carries full burden. It discloses the tool returns signals of diverged co-moving contracts and mentions temporal aspects ('current window'), but lacks details on data freshness, measurement methodology, or any side effects. Basic transparency is present 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 concise sentences efficiently convey the tool's purpose and value proposition. No redundancy, but could be slightly more structured (e.g., separate usage note). Still, it's well within acceptable limits for conciseness.

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

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

Given moderate complexity (2 params, no output schema), the description adequately explains the tool's function and context. However, it omits return format or example output, which would improve completeness for an agent. Still, it provides sufficient context for basic usage.

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

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

Schema description coverage is 100%, with clear parameter descriptions for 'topic' and 'window'. The description adds conceptual context (contagion, divergence) but does not enhance parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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

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

Description clearly states verb (get/surfaces), resource (contracts that co-move and diverge), and unique scope (connected-market signals, divergence). It effectively differentiates from sibling tools like get_market_diff or get_changes by focusing on historical co-movement and current divergence.

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?

Description implies use when looking for diverged co-moving markets but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are named, leaving the agent to infer context from sibling tool names.

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: data freshness ('live exchange data updated every 15 min'), authentication requirements ('No auth needed for global context'), and the two distinct operational modes. It doesn't mention rate limits, error conditions, or response format details.

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 efficiently structured with front-loaded information about global context, followed by thesis-specific details. Every sentence adds value, though the 'START HERE' prefix is slightly redundant and the description could be more streamlined.

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

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

For a tool with 2 parameters, no annotations, and no output schema, the description provides good coverage of functionality and usage modes. However, it lacks details about response format, error handling, and doesn't explain what 'edges' or 'causal tree' mean in this context, which could be important for proper tool selection.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining the functional relationship between parameters: 'With thesisId + apiKey: thesis-specific context' and 'Omit for global market snapshot'. This clarifies how parameter combinations affect tool behavior.

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

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

The description clearly states the tool provides market data and thesis-specific context, with specific resources mentioned (mispriced contracts, price movers, highlights, traditional markets, causal tree, edges with orderbook depth, evaluation history, track record). However, it doesn't explicitly differentiate from siblings like 'get_edges' or 'get_world_state' which might provide overlapping market 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?

The description provides explicit guidance on when to use different modes: 'No auth needed for global context' and 'With thesisId + apiKey: thesis-specific context'. It clearly distinguishes between global snapshot and thesis-specific access, though it doesn't mention alternatives among 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?

No annotations provided; description implies read-only operation and describes outputs, but does not disclose authentication needs, rate limits, or detailed behavioral traits.

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

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

Two sentences with no waste, front-loading the purpose and key outputs.

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; description covers return value types (latest values, percentiles, crosswalks). Could benefit from more detail on format or structure, but sufficient for a moderately complex 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 for both parameters. The description adds minimal new information beyond clarifying the source (FRED) and context (macro anchors).

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

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

The description clearly states the tool retrieves macro/economic anchors from FRED, providing latest values, percentiles, and crosswalks to prediction markets, distinguishing it from other data retrieval tools.

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

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

Indicates usage for grounding macro theses, but does not explicitly mention when not to use or suggest alternatives among siblings.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the ranking mechanism (by edge size), the effect of auth (public vs. private+public edges), and the focus on model-market disagreement. However, it lacks details on rate limits, error handling, or output format, which would be needed for a perfect score.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by clarifying details in two concise sentences. Every sentence adds value (e.g., explaining auth impact), with no wasted words or redundancy, making it highly efficient.

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

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

Given the complexity (4 parameters, no annotations, no output schema), the description is adequate but has gaps. It covers the purpose, auth context, and ranking logic, but lacks details on output format, error cases, or deeper behavioral aspects like pagination. This makes it minimally viable for a tool with this parameter count and no structured support.

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

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

Schema description coverage is 100%, so the schema already documents all parameters (limit, venue, apiKey, minEdge). The description adds marginal value by implying the apiKey's role in auth (private vs. public edges), but does not provide additional semantics beyond what the schema offers, such as explaining 'edge' units or venue specifics.

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: it retrieves 'Top mispriced markets across all theses, ranked by edge size' and explains that it 'Shows where your model disagrees with the market.' This specifies the verb (get/retrieve), resource (edges/mispriced markets), and scope (across all theses), distinguishing it from siblings like get_markets or get_forecast by focusing on edge-based ranking of mispricing.

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

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

The description provides clear context for when to use it: to find mispriced markets based on edge size. It distinguishes between public and private edges based on auth presence, but does not explicitly mention when not to use it or name specific alternatives among siblings (e.g., scan_markets or screen_markets might be related but are not referenced).

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool as retrieving aggregated data over time, which implies a read-only operation, but does not specify aspects like rate limits, authentication needs (beyond the apiKey parameter), data format, or pagination. This leaves gaps in understanding how the tool behaves in practice.

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

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

The description is concise and front-loaded, consisting of two short sentences that directly state the tool's function and usage. There is no wasted language, and it efficiently communicates the core purpose without unnecessary elaboration.

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 (a read operation with 2 parameters) and the absence of annotations and output schema, the description is moderately complete. It explains what data is retrieved but lacks details on return values, error handling, or behavioral constraints. This is adequate for a basic tool but leaves room for improvement in guiding the agent fully.

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

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

Schema description coverage is 100%, with both parameters (thesisId and apiKey) documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as explaining how the thesisId relates to evaluations or the aggregation process. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 retrieve 'daily aggregated evaluations for a thesis' and analyze 'confidence trajectory over time.' It specifies the resource (thesis evaluations) and the verb (get/analyze), but does not explicitly differentiate from siblings like 'get_milestones' or 'get_world_state,' which might also involve thesis-related 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?

The description mentions 'use to analyze trends, detect convergence/divergence,' which implies a context for usage but does not provide explicit guidance on when to use this tool versus alternatives. No sibling tools are referenced, and there is no mention of prerequisites or exclusions, leaving the agent to infer usage based on the purpose alone.

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

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

No annotations provided. Description only states basic behavior (returns evaluations, ordered descending). It does not disclose important details like pagination behavior via the limit parameter, authentication requirements beyond mentioning apikey, or whether results are filtered by user.

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?

Extremely concise single sentence. Front-loaded with the key purpose. Every word is necessary and 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 the tool is a straightforward list, the description is adequate but lacks details that would help an agent choose it over siblings like get_evaluation_history. No output schema means the description could clarify return format. Also no mention of rate limits or other behavioral constraints.

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% (all three parameters have descriptions). The tool description adds no additional meaning beyond the schema for the parameters. Baseline 3 is appropriate.

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

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

Purpose is clear: returns evaluations across all theses, ordered descending. The description also mentions it powers the CLI. It implicitly distinguishes from per-thesis evaluation tools like get_evaluation_history by emphasizing cross-thesis aggregation, but does not explicitly differentiate 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?

No explicit when-to-use or alternatives. The description implies it's for a broad overview, but provides no guidance on when not to use or how it compares to get_evaluation_history or other similar tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'recent trade fills' but doesn't specify time ranges, pagination, rate limits, authentication needs beyond the apiKey parameter, or what 'Advanced:' entails operationally. This leaves significant gaps for a tool that likely involves financial data access.

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—a single sentence with no wasted words. It's front-loaded with the key information ('recent trade fills on Kalshi'), and the 'Advanced:' prefix, while minimal, adds context efficiently. Every part earns its place.

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

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

Given no annotations, no output schema, and a tool that likely returns financial data (trade fills), the description is incomplete. It doesn't explain return values, error conditions, or behavioral traits like data recency or access constraints. For a tool with potential complexity in a trading context, this is inadequate.

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

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

Schema description coverage is 100%, with both parameters (apiKey and ticker) well-documented in the schema. The description adds no additional parameter semantics beyond implying filtering by 'recent' and 'Kalshi', which are already covered or inferred. This meets the baseline for high 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 verb ('get') and resource ('recent trade fills on Kalshi'), making the purpose specific and understandable. It distinguishes from siblings like 'get_orders' or 'get_settlements' by focusing on trade fills, though it doesn't explicitly contrast with them. The 'Advanced:' prefix adds context but doesn't detract from clarity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions 'Advanced:' which might imply it's for experienced users, but offers no explicit when/when-not rules or references to sibling tools like 'get_orders' or 'get_settlements' for comparison. Usage is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool shows 'how market consensus shifted over time' which implies historical trend analysis, but doesn't disclose authentication requirements (though the apiKey parameter hints at this), rate limits, data freshness, or what format the percentile distribution is returned in. For a financial data tool with zero annotation coverage, this is insufficient.

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, efficient sentence that conveys the core functionality. The 'Advanced:' prefix could be considered slightly redundant but doesn't significantly detract. The sentence is front-loaded with the main purpose and doesn't waste words.

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

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

For a financial data tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (beyond mentioning percentile distributions), doesn't specify data formats or units, and provides no context about Kalshi events themselves. Given the complexity of financial forecasting data and lack of structured output documentation, more completeness 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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema - it doesn't explain how the 'days' parameter relates to the percentile calculations or provide examples of event ticker formats. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool retrieves percentile distribution data (P50/P75/P90) for a Kalshi event and shows how market consensus shifted over time. It specifies the resource (Kalshi event) and verb (get/show distribution), but doesn't explicitly differentiate from sibling tools like 'get_markets' or 'scan_markets' which might provide related market 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_markets' or 'scan_markets' that might provide overlapping functionality, nor does it specify prerequisites beyond the implied need for a Kalshi event ticker. The 'Advanced:' prefix suggests specialized use but offers no concrete 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?

No annotations are provided, and the description does not disclose error handling (e.g., missing slug), idempotency, or any side effects. It only states it 'gets' data, which is safe by default, but lacks behavioral details.

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

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

The description is one short sentence with no redundant words. It is appropriately concise for a simple tool, though it could be slightly more structured.

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

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

For a one-parameter read tool without an output schema, the description is adequate but could specify the return format (e.g., object with definition and links) to 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?

The input schema has 100% coverage with a description for 'slug'. The description adds no extra meaning beyond the schema, so it meets the baseline but does not enhance 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 action (Get), the resource (single glossary term), and the output (full definition and links). It effectively distinguishes from siblings like list_glossary.

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

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

No explicit guidance on when to use this tool versus alternatives. It implies usage for retrieving a single term, but does not mention when to prefer it over list_glossary or other get tools.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the tool returns config and cost summary, but does not mention side effects, permissions, rate limits, or whether it is read-only. For a read operation, this is minimal but not misleading.

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 very short (one sentence), which is concise but arguably under-specified. It lacks structure or front-loading of key details. While every word serves purpose, more context could be added without verbosity.

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

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

No output schema exists, and the description only briefly mentions return content (config + monthly cost summary). Given the tool's simplicity and high schema coverage, it is adequate but could be improved by listing specific config fields or cost details to fully inform invocation.

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

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

Input schema coverage is 100%, with both parameters (apiKey, thesisId) already described in the schema. The description adds negligible extra meaning beyond what the schema provides. A baseline score of 3 is appropriate given high 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 gets heartbeat config and monthly cost summary for a thesis, and explicitly identifies it as an alias of get_heartbeat_status. This provides a specific verb-resource pair and clarifies its relationship to a sibling tool.

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

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

No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. Given the sibling set includes a nearly identical name (get_heartbeat_status), explicit guidance would be helpful.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It implies a read-only operation ('Get'), but doesn't specify if it requires specific permissions, has rate limits, returns real-time or cached data, or details error conditions. The mention of 'scan intervals' and 'budget usage' hints at monitoring behavior, but lacks operational clarity for safe invocation.

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, efficient sentence that front-loads the core purpose. The additional detail about 'news/X scan intervals, model tier, budget usage' is relevant but could be slightly more integrated. Overall, it's appropriately sized with minimal 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?

For a read-only tool with 2 parameters and no output schema, the description covers the basic purpose but lacks completeness. Without annotations or output schema, it should ideally specify return format, error handling, or data freshness. The mention of specific data points helps, but doesn't fully compensate for missing behavioral 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 description coverage is 100%, with both parameters (thesisId, apiKey) well-documented in the schema. The description adds no parameter-specific information beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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

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

The description clearly states the tool retrieves 'heartbeat config + this month's cost summary for a thesis', specifying both the resource (thesis) and what data is returned (config and cost summary). It distinguishes from siblings like 'get_balance' or 'get_milestones' by focusing on heartbeat-specific monitoring data, though it doesn't explicitly contrast with them.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'get_balance' (for general balance) or 'configure_heartbeat' (for setup). It mentions 'See news/X scan intervals, model tier, budget usage' as data points, but this is output detail, not usage context. No exclusions or prerequisites are stated.

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

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

No annotations are provided, so the description carries the full burden. It describes the output as a 'curated summary view' but does not disclose potential side effects, data sources, or access requirements. It is a read operation but not explicitly stated.

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 superfluous words. It is front-loaded with the purpose and provides specific examples. Every sentence earns its place.

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

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

For a tool with no parameters and no output schema, the description is reasonably complete but could add more context about return format (e.g., is it a list of items?), ordering, or data recency. It covers the basic purpose but lacks some operational details.

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

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

There are no parameters, so by baseline it scores 4. The description adds meaning about the content of the output (top movers, divergences, etc.), which is helpful beyond the empty schema.

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

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

The description clearly states the tool provides 'editorial highlights for the day' with specific examples like 'top movers, divergences, fresh contagion, freshly-resolved markets'. It is a specific verb+resource (get highlights) and distinguishes from siblings like get_feed or get_briefing.

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 a curated daily summary but does not explicitly state when to use versus alternatives or any exclusions. There is no guidance on context or when not to 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?

The description discloses update frequency ('Pre-computed every 15 minutes') and data start date ('stored since v2 launch (2026-04-09)'), adding value beyond annotations (which are absent). However, it omits key behavioral details like read-only nature, rate limits, or output format, limiting transparency.

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

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

The description is extremely concise, with two short sentences front-loading the purpose and adding essential details. No extraneous 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 simple tool with one optional parameter and no output schema, the description provides sufficient context: purpose, data freshness, and storage start date. It adequately informs an agent, though output structure is omitted.

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?

Input schema covers the only parameter ('days') with a description. The tool description adds no additional meaning beyond the schema, 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 clearly states it provides 'Historical SimpleFunctions Index snapshots' and 'For charting trends,' indicating the resource and action. However, it does not explicitly differentiate from sibling tools like get_market_index or get_market_history, leaving room for confusion.

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

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

The description implies usage for charting trends but offers no explicit guidance on when to use this tool versus alternatives, nor any conditions or exclusions. Given many sibling get_* tools, this is insufficient for optimal 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?

No annotations provided, so the description bears full burden. It does not disclose any behavioral traits (e.g., read vs. write, authentication needs, rate limits, or output behavior). The phrase 'prediction-market cross-reference' hints at extra data but is insufficient.

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

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

The description is a single concise sentence with no extraneous information. It could benefit from slight structuring (e.g., listing behavior), but it is short and front-loaded.

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

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

Given the low complexity (one parameter, no output schema), the description is minimally adequate. It provides the core purpose but lacks completeness regarding return format or any side effects. A more complete description would help the 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?

The single parameter 'billId' is fully described in the input schema with an example. The description adds minimal value beyond the schema, mentioning prediction-market cross-reference but no additional parameter context. Schema coverage is 100%, so baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves bill details and mentions a prediction-market cross-reference. It explicitly calls itself an alias of 'legislation', helping differentiate from a direct sibling. However, it could be more specific about the nature of the 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?

No guidance on when to use this tool versus alternatives. While it mentions being an alias, it does not explain the context for using this over other related tools like 'list_legislation' or 'legislation'.

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

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

No annotations are provided, so the description carries full burden. It clarifies the output is 'raw JSON only', a behavioral trait. However, it does not disclose potential side effects, authorization requirements, or rate limits, leaving some behavioral gaps.

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

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

The description is extremely concise: two sentences with no redundant information. It front-loads the primary purpose and immediately provides context that distinguishes it from a sibling, making every word earn its place.

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

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

Given no output schema, the description lists key return elements (price, volume, indicators, etc.) and compares to 'inspect_ticker'. The sibling context is large, but the description fully captures the tool's role and output, making it complete for its 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?

The input schema covers both parameters ('ticker', 'depth') with descriptions, achieving 100% coverage. The description does not add new meaning beyond the schema, meeting the baseline expectation but not exceeding it.

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

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

The description clearly states the tool retrieves full detail for a single market, listing specific data types (price, volume, indicators, etc.). It explicitly distinguishes from the sibling 'inspect_ticker' by noting it is lower-level and returns raw JSON only, making the purpose 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 provides a clear comparison with the sibling 'inspect_ticker' (lower-level vs. higher-level), which helps the agent decide which tool to use. However, it does not explicitly state when not to use this tool or mention alternatives among other 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?

No annotations are provided, so the description must disclose behavioral traits. It mentions comparing to a prior window and outputs, but does not clarify side effects (e.g., read-only), authentication needs, or rate limits. The description is adequate 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?

The description is two sentences, front-loaded with the main action and outputs. Every sentence serves a purpose, with no redundant information. Highly efficient.

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

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

For a tool with 4 parameters, no required fields, and no output schema, the description covers the core purpose and a typical use case. It lacks details on return format or edge cases, but given the tool's simplicity, it 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 description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema; it mentions output deltas but not how parameters like 'sort' or 'window' work. Minimal added value.

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

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

The description clearly states the tool's action (diff), resource (market), and specific outputs (price delta, volume delta, indicator drift). It also provides a concrete use case ('what changed in the last 6h?'), distinguishing it from sibling tools like get_changes or get_world_delta.

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

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

The description gives a clear usage scenario ('For what changed in the last 6h? questions'), implying when to use it. However, it does not explicitly state when not to use it or mention alternatives among siblings, leaving some inference needed.

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

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

With no annotations, description carries full behavioral burden. It discloses the rolling 7-day window and that it returns price+indicator history, but omits specifics like which indicators, data resolution, or response format. Acceptable but leaves questions about exact output.

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 compact sentences. First sentence states action and scope, second provides usage context. Every word earns its place with no redundancy.

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

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

No output schema and description does not hint at return structure (e.g., array of objects, fields). For a charting/data tool, this leaves ambiguity. However, for a simple single-param tool, the description is minimally adequate.

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

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

Schema coverage is 100%, but description adds meaning beyond the schema: 'for a single market' clarifies the ticker's context and that it's not for indices or batches. This elevates from baseline 3 to 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?

Description clearly states 'Get rolling 7-day price + indicator history for a single market', specifying the exact data scope and time window. It distinguishes from siblings like get_index_history (which is for indices) and get_market_detail (which provides different 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 mentions two use cases: 'For trajectory questions and chart rendering', giving clear context for when to use. Does not explicitly exclude when not to use or name alternatives, but the guidance is sufficient for a focused data retrieval tool.

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

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

With no annotations, the description provides partial transparency: update frequency (every 15 minutes) and value ranges. However, it does not disclose behavior like rate limits, authentication requirements, or consequences of calling between updates.

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, front-loaded with purpose, no unnecessary words. Efficiently conveys purpose and key 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?

No output schema, but description adequately explains return values (four gauges with ranges). Could be more complete by specifying the output structure (e.g., object with named fields), but sufficient 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?

Input schema has zero parameters (100% coverage), so baseline is 4. The description adds meaning about the output (four gauges with ranges) which helps the agent understand what to expect.

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 retrieves the prediction market index with specific gauges (disagreement, geoRisk, breadth, activity) and their ranges. It distinguishes from 'get_index_history' by implying current snapshot.

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

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

No explicit guidance on when to use this tool vs alternatives like 'get_index_history' or other data tools. The description only mentions update frequency but no context on appropriate 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 are provided, so the description must cover behavioral traits. It mentions the tool returns time series data but does not disclose data retention, update frequency, error handling, or any side effects. The lack of behavioral context limits tool selection.

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, each adding clear value: the first defines the output, the second states the usage. No wasted words, well-front-loaded.

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

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

With no output schema, the description lists the returned metrics, which partially compensates. However, it lacks details on data structure (e.g., array of objects, timestamps). Still, it provides sufficient context for a simple time series 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?

All three parameters have descriptions in the input schema (100% coverage), so the baseline is 3. The description adds context about the output metrics, but no additional parameter 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 returns per-ticker microstructure time series with specific metrics like implicit yield, CRI, etc., and explicitly mentions its use for charting indicator drift. This effectively distinguishes it from siblings like get_market_history.

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 charting indicator drift but does not explicitly compare to alternative tools or provide when-not-to-use guidance. Without clear differentiation, an agent might not know when to choose this over similar tools like get_market_history.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what data is returned (market prices) and the default behavior (core 5 markets). However, it doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or error handling. The description adds some context but leaves significant gaps.

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

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

The description is appropriately concise with two sentences. The first sentence states the core purpose and default behavior. The second sentence explains the parameter usage with specific examples. Every sentence earns its place, though the second sentence is somewhat dense with multiple topic examples packed together.

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 (1 optional parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It explains what data is returned and how to use the parameter, but doesn't describe the return format, data structure, or any limitations. For a data retrieval tool with no output schema, more information about the response would be helpful.

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 for its single parameter, so the baseline is 3. The description adds significant value by explaining the parameter's purpose ('Use topic for deep dives') and providing concrete examples of what each topic value returns (e.g., 'energy (WTI, Brent, NG, Heating Oil)'). This goes beyond the schema's generic description and helps the agent understand the parameter's practical use.

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: 'Get traditional market prices via Databento.' It specifies the verb ('Get') and resource ('traditional market prices'), and mentions the data source. However, it doesn't explicitly distinguish this tool from sibling tools like 'scan_markets' or 'screen_markets', which appear related but have different purposes.

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 usage guidance: 'Default: SPY, VIX, TLT, GLD, USO. Use topic for deep dives...' It explains when to use the optional parameter (for specific topic areas) versus when to omit it (for core 5 markets). However, it doesn't explicitly state when NOT to use this tool or mention alternatives among siblings like 'scan_markets' or 'query_databento'.

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

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

With no annotations provided, the description carries the full burden. It discloses that 'No auth required' which is valuable behavioral context about authentication requirements. However, it doesn't mention rate limits, pagination behavior, error conditions, or what format the events are returned in. The description adds some value but leaves significant behavioral aspects unspecified.

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 - just two sentences that each earn their place. The first sentence states the purpose and scope, the second provides important behavioral context about authentication. There's zero wasted language or redundancy.

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

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

For a read-only tool with 2 parameters and 100% schema coverage but no output schema, the description provides adequate but minimal information. It covers the purpose and authentication context but doesn't describe the return format or data structure. Given the lack of output schema, the description could do more to explain what the tool returns.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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

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

The description clearly states the verb ('Get') and resource ('upcoming events from Kalshi calendar'), specifying the content type ('economic releases, political events, catalysts'). It distinguishes from siblings like get_schedule or get_markets by focusing on calendar events rather than trading schedules or market 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?

The description provides clear context for when to use this tool ('Get upcoming events from Kalshi calendar') and mentions 'No auth required' which is helpful guidance. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools, though the purpose naturally differentiates it from most siblings.

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

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

No annotations are available, so the description must bear the full burden. It only states 'recently-listed' and 'fresh opportunities' but fails to disclose what 'recently' means, data freshness guarantees, rate limits, or any mutation behavior. The description is too vague.

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 very short (two sentences) and front-loaded with the core purpose. No unnecessary information, but it could be slightly more informative without being 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?

With 4 parameters and no output schema, the description is minimal. It does not explain the return format, pagination, or the exact definition of 'new' (e.g., hours-based). Given many sibling tools, more context would help the agent select correctly.

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

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

The input schema has all four parameters described, achieving 100% coverage. The description does not add extra meaning beyond the schema, so the 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 clearly states 'recently-listed markets' and specifies the venues (Kalshi and Polymarket), which distinguishes it from sibling tools like get_markets or scan_markets. The purpose is specific and actionable for finding fresh trading opportunities.

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 finding fresh opportunities but does not explicitly state when to use this tool versus alternatives like get_markets or scan_markets. No guidance on when not to use it is provided.

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 must fully convey behavioral traits. It implies a read-only operation but does not disclose failure behavior (e.g., invalid slug), rate limits, or whether full content is returned. The agent lacks crucial behavioral context.

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

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

The description is a single concise sentence, front-loaded with the action and resource. Every word is necessary, but it could be slightly more informative without losing conciseness (e.g., specifying that it returns the full essay).

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

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

Given no output schema and no annotations, the description leaves ambiguity about the response structure. The agent does not know if it returns content, metadata, or both. Siblings like 'get_context' suggest similar retrieval but differ in scope, yet this is not clarified.

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 describes the 'slug' parameter. The description merely repeats 'by slug', adding no further meaning (e.g., format, endpoint variations). Baseline 3 is appropriate as the description adds no extra value.

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

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

The description clearly states the tool retrieves a single opinion/essay identified by a slug. The verb 'Get' and resource 'opinion/essay' are specific. However, it does not differentiate from siblings like 'get_answer' or 'get_context', nor does it highlight that 'list_opinions' is for multiple opinions.

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

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

No guidance is provided on when to use this tool versus alternatives. For instance, it doesn't mention that this is for fetching one specific opinion, while 'list_opinions' returns a list. There are no conditions, prerequisites, or exclusions stated.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'resting orders' which implies read-only retrieval of pending orders, but doesn't specify authentication requirements (beyond the apiKey parameter), rate limits, pagination, error conditions, or what data is returned. For a financial API tool with zero annotation coverage, this is insufficient.

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 (6 words) and front-loaded with the core functionality. However, the 'Advanced:' prefix adds minimal value and could be considered slightly wasteful. Overall, it's efficient but could be more informative.

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 financial trading API tool with no annotations and no output schema, the description is inadequate. It doesn't explain what data is returned (order details, format, structure), doesn't mention authentication requirements beyond the parameter, and provides no context about Kalshi's platform. The description should do more to compensate for the lack of structured metadata.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters (apiKey and status). The description doesn't add any parameter semantics beyond what's in the schema - it doesn't explain what 'resting orders' means in relation to the status parameter or provide context about Kalshi's order lifecycle. Baseline 3 is appropriate when schema does the documentation work.

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

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

The description clearly states the verb ('get') and resource ('current resting orders on Kalshi'), making the purpose specific and understandable. It doesn't explicitly distinguish from sibling tools like 'get_fills' or 'get_settlements', but the resource specificity ('resting orders') provides implicit differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'get_fills' (for executed orders) or 'cancel_intent' (for order management). The 'Advanced:' prefix is vague and doesn't clarify appropriate contexts or prerequisites for usage.

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, so description must disclose behavior. It states it's a read operation with live P&L, but does not detail return format, error conditions, or permissions beyond apiKey. Could be more 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?

Single sentence, all content valuable, front-loaded with purpose and contrast.

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; description mentions live P&L but does not specify the output structure or potential errors. Adequate for a simple read but not fully 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% and parameter already well-described. Description adds no extra parameter details.

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

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

Description clearly states it reads positions (not mutates) with live P&L, and distinguishes from sibling mutate tools like add_position/close_position/update_position.

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 it is the counterpart to add_position/close_position/update_position and reads, so agent knows when to use this vs those.

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

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

No annotations are provided, so the description carries full responsibility. It only states the basic purpose without disclosing behavioral traits such as read-only nature, error handling (e.g., missing slug), or any side effects. The description is insufficient for an agent to understand behavior beyond the core 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?

The description is a single sentence that is concise and front-loaded. Every word carries meaning, and there is no fluff. It efficiently communicates the core function.

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

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

Given the tool's simplicity (one parameter, no output schema), the description provides the essential purpose but lacks details like how to identify a published skill, typical return structure, or error cases. It is minimally complete but could benefit from a hint about the response format.

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 schema already documents the 'slug' parameter. The description adds marginal value by confirming the slug is for a published skill. Baseline 3 is appropriate as the description does not deepen understanding 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 'Get a single published skill by slug' clearly specifies the action (get), resource (a single published skill), and the method (by slug). It distinguishes from siblings like 'browse_public_skills' (likely listing) and 'get_skills' (possibly private).

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

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or conditions like needing a slug. There are no 'when to use' or 'when not to use' instructions.

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

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

No annotations are provided, so the description bears full behavioral disclosure burden. It mentions label transitions and examples but lacks details on error handling, output format, pagination, or authentication needs. The description is insufficient for safe agent invocation.

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

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

The description is a single sentence with an illustrative example in parentheses, conveying the core purpose without extraneous text. It is front-loaded 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?

The tool is simple with only two optional parameters, but no output schema exists. The description lacks details on the return format (e.g., list of objects, time-series) and default behavior when parameters are omitted. Adequate but has 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?

The input schema covers both parameters (limit, ticker) with descriptions, achieving 100% coverage. The description adds an example of regime labels but does not explain parameter usage, defaults, or constraints beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states what the tool does: retrieving historical regime labels for a ticker, with explicit examples of label transitions. It distinguishes itself from sibling tools like get_regime_scan by focusing on historical time-series 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?

The description implies usage for historical data but does not explicitly state when to use this tool over alternatives (e.g., get_regime_scan) or provide conditions for use. No exclusions or when-not-to-use guidance are given.

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

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

No annotations provided; description carries full burden. It fails to mention behavioral traits like read-only nature, pagination, rate limits, or authentication requirements. The description is too brief for a tool with no 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 sentences with no filler. Front-loaded with purpose and regime labels. Could be slightly more structured but remains concise and to the point.

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?

Adequate for a simple scan tool with fully described schema. Lacks details on output or return format since no output schema exists. For a tool with 7 parameters and no annotations, more context would help.

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

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

Schema description coverage is 100%, so parameters are already documented. The description adds 'with optional indicator filters' as context but doesn't elaborate on specific parameters beyond the schema. 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?

Description clearly states 'Scan markets by regime label' with enumerated labels, and adds 'with optional indicator filters'. It distinguishes its regime-based focus from generic scanning tools, but doesn't explicitly differentiate from siblings like scan_markets or screen_markets.

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?

Implied usage: regime-based screening. No explicit when-to-use, when-not-to-use, or alternatives. The phrase 'For regime-based screening' gives context but lacks guidance on selecting this tool over similar ones.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('get') but doesn't specify whether it requires authentication, has rate limits, returns real-time or cached data, or details the response format. This leaves significant gaps for a tool that likely interacts with market data.

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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and wastes no words, making it ideal for quick comprehension.

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 likely complexity (providing exchange status and trading hours), the description is minimal. With no annotations and no output schema, it lacks details on authentication needs, data freshness, or return structure. However, for a zero-parameter tool, it meets a basic threshold but could be more informative about behavioral aspects.

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

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

The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, earning a baseline high score since it doesn't need to compensate for any gaps.

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 with specific verbs ('get') and resources ('exchange status and trading hours'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'get_markets' or 'get_balance' that might also provide related market information, preventing a perfect 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 provides no guidance on when to use this tool versus alternatives like 'get_markets' or 'get_forecast', nor does it mention any prerequisites or exclusions. It merely states what the tool does without contextual usage information.

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

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

No annotations are provided, so the description carries full burden. It mentions 'advanced' and 'realized P&L' but doesn't disclose behavioral traits like whether this is a read-only operation, authentication requirements beyond the apiKey parameter, rate limits, or what the output format looks like. For a financial data tool with no annotations, this leaves significant gaps in understanding its 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, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a simple data retrieval tool, though it could be slightly more structured by separating purpose from context.

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

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'settled contracts' entail, how 'realized P&L' is calculated, or what the return data looks like. For a financial tool with potential complexity, this leaves too much undefined for effective agent use.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (apiKey and ticker). The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining how ticker filtering works or providing examples. With high schema coverage, the 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 states the tool retrieves 'settled contracts with realized P&L,' which is a clear verb+resource combination. It specifies 'advanced' context and includes 'realized P&L' to differentiate from generic settlement data. However, it doesn't explicitly distinguish from siblings like get_fills or get_orders, which might also involve financial transactions.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions 'advanced' but doesn't clarify what makes it advanced or when to prefer it over other financial data tools like get_fills or get_orders. There are no explicit when/when-not statements or named 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, but the description implies a read-only, authenticated operation and scopes to the user's own skills. Does not detail error cases or side effects, but for a list operation, this is adequate.

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?

Exceptionally concise: one sentence plus a parenthetical note. Every word adds value, no redundancy.

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

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

For a simple list tool with good schema coverage and no output schema, the description fully covers purpose, scope, and alternative tool. 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 coverage is 100% for the single parameter (apiKey). The description adds context by linking the apiKey to the authenticated user, going beyond the generic 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 the tool lists the authenticated user's skills, distinguishing it from the sibling tool 'browse_public_skills' for public skills.

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 when to use this tool (own skills) and directs to 'browse_public_skills' for public skills, providing clear usage 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?

With no annotations, the description carries the full burden but only states the action. It does not disclose any behavioral traits such as rate limits, authentication needs, or side effects. For a read-only tool, it minimally conveys no side effects.

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

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

The description is a single sentence with 7 words, front-loaded with the verb and resource, and contains 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?

Given the simplicity of the tool (one param, no output schema), the description is minimally adequate but lacks context about the return value or behavior. It is not incomplete but could be more helpful.

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

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

Schema description coverage is 100%, so the schema already documents the 'slug' parameter. The description adds no extra meaning beyond what the schema provides, meeting the baseline of 3.

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

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

The description clearly states the verb 'Get' and the resource 'technical reference doc', with the parameter 'slug' mentioned. It distinguishes from siblings like get_glossary_term by specifying 'technical reference doc'.

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

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

No guidance on when to use this tool versus alternatives like get_glossary_term or get_market_detail. The description does not provide context for usage exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It mentions 'Auth-only' hinting at authentication needs but does not disclose behavioral traits like error handling, rate limits, or what happens if the thesisId is invalid. The description focuses on content rather than 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 two sentences long, front-loading the key information in the first sentence and providing usage guidance in the second. No redundant text; 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 the moderate complexity (2 params, no output schema), the description lists the specific data elements returned (causal tree, edges, evaluation history, track record), providing a good sense of the output. However, it does not specify the return format or whether pagination applies, which would elevate completeness further.

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 two string parameters (apiKey, thesisId). The description adds no additional meaning beyond the schema; it does not explain the format or constraints of these parameters. Baseline 3 is appropriate as schema already covers them.

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 what the tool does: returns a thesis-specific context including causal tree, edges with orderbook depth, evaluation history, and track record. It distinguishes from sibling tool 'get_context' by noting that 'get_context' without thesisId provides the global snapshot.

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 this tool (for a specific thesis) and provides an alternative: 'Use get_context with no thesisId for the global market snapshot.' This leaves no ambiguity.

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

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: 'No auth required' (permissions), and details about idea structure ('conviction level, catalyst timing, direction, and risk'). However, it doesn't mention rate limits, pagination, or response format specifics that would be helpful for a tool returning recommendations.

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 efficiently structured with three sentences that each serve distinct purposes: defining the tool, detailing its output characteristics, and providing usage guidance. No wasted words or redundancy.

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

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

For a tool with no annotations and no output schema, the description does well by explaining the nature of the recommendations and their components. However, it doesn't describe the return format or structure of the trade ideas, which would be valuable given the absence of an output schema.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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

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

The description clearly states the tool's purpose: 'S&T-style trade recommendations: actionable pitches synthesized from live market data, edges, and macro context.' It specifies the verb ('recommendations') and resource ('trade ideas'), and distinguishes it from siblings by emphasizing it's the starting point for finding trades.

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 usage guidance: 'START HERE when looking for what to trade.' This clearly indicates when to use this tool versus alternatives among the many sibling tools, establishing it as the primary entry point for trade discovery.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the incremental nature (only changes since timestamp), performance characteristics (~30-50 tokens vs 800 for full state), and the intended use case (periodic refresh). However, it doesn't mention error handling, rate limits, or authentication needs.

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 and front-loaded: the first sentence states the core purpose, the second provides performance context, and the third gives usage guidance. Every sentence earns its place with no wasted words.

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

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is fairly complete. It explains what the tool does, when to use it, and performance characteristics. However, it lacks details on return values or error conditions, which would be helpful since there's no output schema.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate coverage without extra value.

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

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

The description clearly states the tool's purpose: 'Incremental world state update — only what changed since a timestamp.' It specifies the verb ('update'), resource ('world state'), and scope ('incremental'), and distinguishes it from sibling tools like 'get_world_state' by emphasizing the delta approach.

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 this tool: 'For periodic refresh during long tasks.' It also implies an alternative by contrasting with 'full state' (likely referring to 'get_world_state'), providing clear context for usage vs. other options.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It discloses key behavioral traits: 'real-time world model,' token budget (~800 tokens), content scope, prediction market probabilities, always-present anchor contracts, and explicitly states 'No auth needed.' This provides comprehensive operational context beyond what the input schema covers.

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 exceptionally concise and well-structured. Every sentence adds value: first establishes the core purpose, second specifies content scope and token budget, third mentions key features (prediction markets, anchor contracts), fourth states authentication status. Zero wasted words, perfectly front-loaded with the most important information first.

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 (real-time world model with multiple content domains) and no annotations or output schema, the description provides excellent coverage. It explains what the tool returns (world model with specific content areas), format considerations (token budget), key features (prediction markets, anchor contracts), and operational constraints (no auth needed). The only minor gap is lack of explicit output format details, though the input schema covers this.

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