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. It implies a write operation ('Record') but discloses no side effects, idempotency, authorization requirements beyond the schema's apiKey, or what happens on duplicate positions. This is a significant transparency gap 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?

Two short sentences: the first states the purpose, the second states when to use it. There is no filler, and the information is front-loaded. Every word adds value.

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

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

For a tool with 9 parameters, no annotations, and no output schema, the description is under-specified. It lacks any mention of return value, behavior on duplicate positions, or how this relates to close_position and update_position. The schema covers parameters well, but the overall tool 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 all 9 parameters are already documented, including enums for venue and direction and units for entryPrice. The description adds no additional parameter semantics beyond the schema, so a baseline of 3 is appropriate.

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

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

The description uses the specific verb 'Record' with a clear resource ('a new position in a thesis for tracking') and distinguishes from sibling tools like close_position and update_position by focusing on the initial recording action. It is immediately obvious what the tool does.

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

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

Explicitly states 'Use after an intent fills or a manual trade', giving clear timing context for when to use this tool. It does not mention when not to use it or name alternatives, but the guidance is sufficient for a simple recording operation.

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 burden of behavioral disclosure. It explicitly states 'append-only', which is an important non-destructive trait, but it does not mention whether it is a write operation, any permissions required, or what happens on conflicts. The 'Advanced:' prefix hints at complexity but adds no concrete 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, front-loaded sentence that conveys the core action, resource, and key constraint. It contains no filler or redundancy, with '<2' descriptors like 'Advanced:' serving as a brief context cue.

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

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

The description names the operation and source ('evaluations') but does not mention what the tool returns, prerequisites (e.g., having an existing thesis and evaluation suggestions), or behavior in edge cases. With no output schema, some additional context about expected results would improve completeness.

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

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

The schema description coverage is 100%, so all three parameters (apiKey, dryRun, thesisId) are already described. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb 'Merge' and a clear resource ('suggested causal tree nodes from evaluations') and adds a key constraint ('append-only'). This distinguishes it from sibling tools like update_nodes, which likely modify nodes.

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 in the context of evaluations ('from evaluations') but does not explicitly state when to use this tool versus alternatives such as update_nodes or trigger_evaluation. No exclusions or alternative tool names are mentioned.

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

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

No annotations are provided, so the description must carry behavioral transparency. It adds the performance trait 'Cheaper than calling get_market_detail in a loop' but does not disclose potential limits on the number of tickers, pagination, error behavior, or response format. For a simple read operation, this is adequate but not fully transparent.

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

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

The description is a single, well-structured sentence that front-loads the purpose and adds a cost-saving hint. Every word earns its place, and there is no redundant information.

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

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

The tool is simple with schema covering both parameters, and the description names the key use case. However, without an output schema or mention of return structure/limits, an agent might not fully anticipate the response shape. Given the similarity to get_market_detail, this is a minor gap, making it slightly above average 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 description coverage is 100%, so both 'tickers' and 'depth' are already documented in the input schema. The description adds no additional meaning beyond the phrase 'by ticker list,' which merely echoes the schema. It does not explain the relationship between parameters or provide usage syntax beyond what is 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 function: 'Fetch many markets at once by ticker list.' It names a specific verb ('fetch'), resource ('markets'), and method ('by ticker list'), and distinguishes it from the sibling tool get_market_detail by emphasizing the batch nature and cost advantage.

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 provides guidance by comparing to get_market_detail: 'Cheaper than calling get_market_detail in a loop.' This gives a clear when-to-use context. However, it does not mention alternative batch tools like get_markets or scan_markets, nor when not to use it, so it misses explicit 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 must carry the full burden of behavioral disclosure. It does disclose that the tool is free-tier and rate-limited, which is useful operational behavior. However, it does not mention the response format, pagination, or any other behavioral nuances, leaving gaps for an agent to anticipate.

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, consisting of two sentences that front-load the main purpose and then add constraints and filtering options. Every word contributes meaning, with no redundancy or irrelevant detail, 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 tool's low complexity—three optional parameters with full schema descriptions and no required inputs—the description provides sufficient context for an agent to understand what the tool does and its key capabilities. Since there is no output schema, the description need not detail return values, but it could mention pagination or result structure. Overall, it is adequately complete for this simple browse tool.

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

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

The input schema covers all three parameters (q, sort, category) with clear descriptions, achieving 100% coverage. The description's mention of 'filter by category, search, or sort by popularity' merely paraphrases the schema without adding semantic detail, so it stays at the baseline.

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

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

The description clearly states the tool's purpose: 'Browse public skills from the community,' identifying the verb and resource. It also mentions filtering, search, and sorting, which distinguishes it from simple list tools. However, it does not explicitly differentiate it from sibling tools like 'explore_public' or 'list_skills,' so it falls short of 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 context that this is for public community skills and is free-tier with rate limits, which implies suitable use cases. However, it lacks explicit guidance on when to use this tool over alternatives like 'list_skills' or 'get_public_skill,' and does not state any exclusions or prerequisites. The usage scenario is implied but not clearly articulated.

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 burden. It does disclose key behavioral traits (stops trigger evaluation, prevents execution), but it doesn't mention reversibility, idempotency, or what happens to the intent after cancellation.

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 concise, using two short sentences that both add value: one states the primary action, the other clarifies the behavioral outcome.

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

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

For a simple two-parameter tool with no output schema and no annotations, the description covers the core purpose and effect. However, it could be more complete by mentioning whether cancellation is idempotent or what happens if the intent is already executed.

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 no additional parameter semantics beyond what the schema already documents for apiKey and intentId.

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 'Cancel' and the resource 'active intent', and further clarifies the effect by noting it stops trigger evaluation and prevents execution. This distinguishes it from siblings like create_intent or trigger_evaluation.

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 you want to cancel an active intent) but provides no explicit guidance on when to use vs alternatives, nor any prerequisites or exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Delete', which implies destructiveness, but it does not mention whether the action is reversible, any side effects on related data, permission requirements, or what the response will be. This is a minimal disclosure equivalent to the verb itself.

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, front-loaded sentence with no redundant words. It efficiently communicates the core function without any 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?

For a simple delete operation, the description is minimally adequate. However, it does not mention what the tool returns, whether the operation is irreversible, or any preconditions (e.g., position must exist). The schema provides essential parameter context, but the description leaves some gaps in the overall usage picture.

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

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

The input schema provides descriptions for all three parameters (thesisId, positionId, apiKey), giving 100% coverage. The tool description does not add additional parameter semantics, but since the schema already documents them, a 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 states a clear action ('Delete') and a specific resource ('position record from a thesis'). This clearly distinguishes it from sibling tools like add_position, update_position, and get_positions.

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, such as when a position should be removed, prerequisites, or what distinguishes it from close_position-like operations. It simply states the function without contextual 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, the description carries the full burden for behavioral disclosure. It lists the settings and hints at operational effects (monitoring speed, budget), but it does not explain side effects, persistence, reversibility, or prerequisites like requiring an existing thesisId beyond what the schema already states.

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. The first sentence defines scope via a list of configurable aspects, and the second provides a practical use case. No unnecessary words or repetition.

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

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

Given the tool's complexity (9 parameters, mutation) and the absence of both annotations and an output schema, the description is adequate but incomplete. It tells what the tool does and when to use it, but does not mention reading the current config first or the detailed consequences of changes.

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

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

Schema coverage is 100% with detailed descriptions for all 9 parameters, so the baseline is 3. The description adds a general operational framing (e.g., speed vs. budget) but does not deepen understanding of individual parameters 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 identifies the tool's action ('Configure') and resource ('24/7 heartbeat engine'), then enumerates the specific configurable settings (news scan interval, X scan interval, LLM model tier, monthly budget, runtime pause/resume, closed-loop intent creation). This distinguishes it from sibling read-only tools like get_heartbeat_config and get_heartbeat_status.

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 usage context: the agent can use it to speed up monitoring during high volatility or slow down to save budget. However, it does not explicitly mention alternatives (e.g., using get_heartbeat_config to read current settings) or state when not to use the 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?

Given no annotations, the description discloses meaningful behavioral context: a local runtime daemon evaluates triggers and executes via the user's Kalshi/Polymarket keys. This conveys the asynchronous execution model and key-based authorization. It does not mention return values or confirmation steps, but the disclosed mechanism goes beyond a simple tautology.

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 exactly two sentences, front-loaded with purpose, and includes a concrete example plus architectural context. Every word earns its place; there is no redundancy or fluff.

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

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

The description explains the core concept and execution model, and the schema covers parameters thoroughly. However, with no output schema, the description lacks any indication of what the tool returns or the immediate result of creating an intent (e.g., intent ID, status). For a complex tool with 15 parameters, this gap is notable.

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

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

The schema provides 100% description coverage for all 15 parameters, including enums, defaults, and examples. The description adds no additional parameter semantics beyond the illustrative 'buy X when condition Y, expire at Z' example, which maps to action, targetQuantity, triggerType, and expireAt but does not enrich 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 names the operation 'Declare an execution intent' and states it is the single gateway for all order execution, distinguishing it from sibling tools like cancel_intent or get_orders. The verb 'Declare' is specific and the resource is unambiguous.

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

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

The phrase 'single gateway for all order execution' gives clear context that this is the go-to tool for placing orders, implying use for execution workflows. However, it does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the basic create operation and does not mention potential side effects, idempotency, name uniqueness, authorization requirements, or what happens on failure. This is a significant gap 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 a single, front-loaded sentence that communicates the core purpose without waste. It is 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?

As a mutation tool with no annotations and no output schema, the description should provide more context about expected behavior, such as return values, constraints (e.g., unique skill names), and how it relates to other skill tools. The sparse description is insufficient for the tool's complexity (10 parameters, 5 required).

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 all 10 parameters are already documented with descriptions. The tool description adds no extra parameter-level meaning beyond the schema. Baseline of 3 is appropriate when the schema handles parameter documentation.

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

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

The description states a specific verb+resource: 'Create a custom agent skill' and elaborates with 'reusable prompt/workflow that can be triggered via slash command.' This clearly distinguishes it from sibling skill tools like run_skill (execute), fork_skill (copy), and publish_skill (make 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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention that fork_skill is for reusing existing skills or run_skill for invoking them, nor does it state any exclusions or prerequisites. The usage context is only implied by the 'Create' verb, not explicitly explained.

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 burden of behavioral disclosure. It reveals a key behavior: checks every 15 minutes and executes when conditions are met, implying automated trade execution. However, it does not mention side effects (e.g., order placement), required permissions beyond API key, reversibility, or error handling, which are important for a trading 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 two sentences with no filler. It front-loads the primary purpose and then adds a concise behavioral detail about the heartbeat engine. Every word contributes 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 complex tool with 14 parameters and no output schema, the description provides only basic context: setting up automation and the 15-minute check loop. It does not explain what the tool returns (e.g., strategy ID), how to manage or stop the strategy, or what 'executes' means in practice—gaps that matter for a trading 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 description coverage is 100%, so parameter meanings are fully documented in the schema. The description summarizes some parameters (entry price, stop loss, take profit, soft conditions) but does not add new meaning beyond what the schema already provides (e.g., softConditions is already described as 'LLM-evaluated conditions').

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

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

The description uses a specific verb ('Set up automated trading') and resource (strategy) with clear details about parameters (entry price, stop loss, take profit, soft conditions). It distinguishes itself from sibling tools like create_thesis or add_position by mentioning the automated heartbeat engine and execution behavior.

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

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

The description implies when to use this tool: when you want automated trading with entry/exit conditions and periodic checks. It does not explicitly name alternatives or provide when-not-to-use guidance, but the context is clear enough to differentiate from manual position tools like add_position or close_position.

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 of disclosing behavior. It mentions the process ('Builds a causal tree and scans for mispriced contracts') and timing ('Formation takes ~60s'), which is useful. However, it does not disclose potential side effects (e.g., whether the thesis is published, whether it consumes funds, or what the outcome is). Since this is a creation tool, more explicit behavioral disclosure would be expected.

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: first sentence states the core purpose, followed by examples and process details. Every sentence earns its place with no fluff. The structure is clear and easy to scan.

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

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

For a creation tool with no annotations and no output schema, the description explains the input requirements, the internal process, and the expected duration. It is usable as-is. It could be more complete by mentioning what the tool returns or any prerequisites (e.g., required permissions or linked accounts), but it covers the essential workflow for a thesis creation tool.

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

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

The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds significant value by explaining the 'thesis' parameter in detail with good and bad examples, clarifying what constitutes a valid claim. This enriches the parameter semantics beyond the schema's simple description. No additional meaning is provided for 'sync' or 'apiKey', but the core parameter is well-expanded.

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 from a TESTABLE CLAIM'. It specifies the resource (prediction market thesis), the required input format (testable claim), and distinguishes it from reasoning by providing good/bad examples. This is specific and differentiates it from sibling tools like create_strategy or update_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 provides clear guidance on when to use the tool: when you have a testable claim that can be verified true or false. It reinforces this with concrete examples of valid and invalid claims. However, it does not explicitly name alternative tools or state when NOT to use this tool, so it falls short of a 5.

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

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

With no annotations, the description carries the burden. It adds behavioral notes: 'No auth, no Firecrawl needed' and 'Demo/trial entry point', indicating a lightweight, possibly limited service. Still, it does not disclose read-only status, rate limits, or response format, so only partial 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 two sentences, front-loaded with the primary action. Every phrase earns its place: the resource, the input, the output, and the access prerequisites. No redundant or filler 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?

For a 4-parameter tool with no output schema, the description covers the main use case and access conditions but omits expected return structure or limitations (e.g., what the divergence analysis looks like, any output size constraints). It's adequate for a demo entry point but leaves the agent with some uncertainty.

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema by explicitly tying 'content' and 'topics' to the paste-and-analyze workflow, and explaining that they drive the divergence analysis. It doesn't elaborate on model/includeIndex, but the schema already handles those; the added context for the core required params is valuable.

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

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

The description uses a specific verb ('cross-reference') and resource ('prediction market contracts'), and clearly explains the output ('divergence analysis'). It distinguishes itself from sibling tools like query or scan_markets by specifying the unique input (text + topics) and purpose (sentiment vs market prices).

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 clarifies that no auth or Firecrawl is needed and that this is a demo/trial entry point, which gives some context on when it's appropriate. However, it does not explicitly name alternative tools or state when not to use it, leaving the comparison to siblings implicit.

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 rate-limiting behavior and positionally describes how the tool behaves with or without a slug. It does not mention output format or authentication, but the read-only nature is implied by 'browse public theses'. This is solid disclosure for a simple read 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 consists of two concise sentences. The first front-loads the purpose, and the second covers both usage modes. No redundant or filler content is present.

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, no output schema, and no annotations, the description covers the essential behavior, usage constraints, and parameter semantics. It does not explain what the returned list contains or any pagination, but these are not critical for a basic 'browse' action, so the description is sufficiently complete.

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

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

The schema already provides 100% coverage for the single 'slug' parameter with a clear description. The description's instruction to 'Pass a slug to get details, or omit to list all' essentially paraphrases the schema, adding no new semantic information. Baseline 3 is appropriate given the 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 uses the specific verb 'Browse' and clearly identifies the resource as 'public theses from other users', distinguishing it from sibling tools like 'explore_theses' or 'list_theses'. It also states the primary behavior (pass a slug for details, or omit to list all), making the tool's scope 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 gives clear context for usage: it notes the tool is 'Free-tier and rate-limited' and explains the two invocation modes ('Pass a slug to get details, or omit to list all'). However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explains the parameter behavior (slug for single, omit for list) and implies read-only via 'browse,' but it does not disclose response format, pagination, authentication requirements, or any side effects. Since it is a browse tool, the read-only nature is implied, and the alias to explore_public adds context, but the lack of return/error details keeps it from being 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?

The description is a single, front-loaded sentence that immediately states the purpose. Every phrase adds value: 'Browse public theses' defines the action, 'alias of explore_public' provides context, and the next clause explains the two usage modes. 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?

The tool is simple (one optional parameter, no output schema), so the description covers the basic usage. However, it lacks details about what the response contains, pagination, or whether 'public' means anyone can access without auth. Since there is no output schema and no annotations, the description should compensate more to fully prepare an agent for invoking and interpreting results. It is adequate but has clear 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 parameter schema already describes slug as 'Thesis slug, or empty to list' with 100% coverage. The description adds behavioral nuance ('Pass slug to get one, omit to list') which clarifies the effect of empty vs. populated slug, but it doesn't add new syntax, format, or constraints beyond the schema. This aligns with the baseline of 3 when schema coverage is high.

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 'Browse public theses' with a specific verb and resource. It also distinguishes itself by noting it is an 'alias of explore_public' and explains the two modes: 'Pass slug to get one, omit to list.' This is specific and immediately separates it from siblings like list_theses or get_thesis_context.

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 how to use the tool: pass a slug for a single thesis or omit to list. It also points to the alias of explore_public, which gives a reference for expected behavior. However, it doesn't explicitly mention when to prefer this over list_theses or explore_public, so it lacks explicit exclusions or alternative 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, the description carries the transparency burden. It discloses the core behavior (forking into collection) and a constraint (public skills only). However, it doesn't mention side effects (e.g., whether it overwrites an existing fork), nor does it describe the return value or error cases. This is a minimal but not completely absent 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?

Two short sentences that are front-loaded with the action. The first sentence states what and where; the second gives a specific, useful clarification. There is no wasted wording.

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

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

The tool is simple with two parameters and no output schema. The description covers purpose and a key input detail (no slug needed). It doesn't explain the result of the fork in detail, but given the simplicity and clarity of 'fork into your collection', it is adequately complete for the complexity.

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

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

Schema coverage is 100% and both parameters have descriptions. The description adds value by clarifying the skillId parameter: 'No slug needed — just the skill ID.' This prevents confusion about the ID format and complements the schema's 'Public skill ID to fork'.

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'), the resource ('a public skill'), and the destination ('into your collection'). The note about 'No slug needed' distinguishes it from tools that might require slugs, and the sibling list shows no other fork_skill with this specificity.

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

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

The description gives clear context: it is for forking a public skill into the user's collection. It implies when to use (when you want a copy of a public skill), but it does not explicitly mention alternatives or exclusions. The 'No slug needed' is a useful usage hint that differentiates from slug-based 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 reveals key side effects: clone copies a PUBLIC thesis verbatim into your collection; evolve splits a thesis you own, the parent enters dormant mode, and the child re-runs formation. This goes beyond simple 'fork' semantics and aids risk assessment.

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-loads the verb and resource, and uses a clear two-mode structure. Every sentence earns its place, with no redundant filler or restating of schema fields.

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

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

For a two-mode tool with 6 parameters and no annotations or output schema, the description covers mode selection, ownership constraints, and behavioral consequences. It does not describe the return value or potential errors, which would strengthen completeness, but the core invocation knowledge is present.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful mode-level semantics: calling with just idOrSlug triggers clone, while including newRawThesis triggers evolve. This explains how the parameters interact beyond their individual 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 opens with the specific verb 'Fork' plus the resource 'thesis', and immediately distinguishes two clearly named modes (Clone and Evolve) with distinct outcomes. It differentiates itself from siblings like create_thesis and fork_skill by specifying public-copy and own-thesis-split semantics.

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

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

The description gives clear context for both modes: clone when copying a public thesis, evolve when restructuring your own thesis. It explicitly states 'Use evolve when the current frame is fundamentally inadequate.' It does not explicitly name alternative tools or state when not to use fork, but the mode guidance is sufficient for 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?

With no annotations, the description carries the burden. It communicates that the tool returns a playbook and is meant for guidance, implicitly indicating a read-only, non-destructive action. However, it does not detail return format, behavior when parameters are omitted, or potential side effects, leaving some gaps.

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

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

Two concise sentences, front-loaded with the core purpose, followed by a practical use case. 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?

For a simple, optional-parameter guide retrieval tool, the description covers what it is and when to use it, while the schema covers parameter details. It lacks explicit mention of output format or behavior with no params, but these are not critical for this low-complexity 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 description coverage is 100% and both parameters (q and intent) are well-described in the schema. The description reinforces the intent enum values but adds little beyond what the schema already 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?

Clearly states it is a 'runtime playbook' providing step-by-step workflows for specific intents (query/monitor/integrate). This distinguishes it from the many sibling data-retrieval tools by positioning it as an onboarding/help resource for agents.

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 a clear trigger condition. It does not name alternative tools or when-not-to-use cases, so it stops short of a 5.

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

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

With no annotations, the description carries the burden of disclosing behavior. It states the tool 'returns' data, implying a read-only operation, and mentions the data source. However, it does not explicitly state that it has no side effects, nor does it describe error scenarios or authorization requirements.

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

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

The description is two sentences, front-loaded with the core purpose, and every phrase adds value. It avoids redundancy and is highly scannable.

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 retrieval tool with one parameter, the description covers purpose, returned fields, and data source. No output schema exists, so the explicit mention of probability, confidence, and citations adequately sets expectations for the response.

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 parameter 'slug' is fully described in the schema with an example, providing 100% coverage. The description adds context about the answer card but does not enrich the parameter semantics beyond what the schema already offers.

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 a pre-computed answer card for a probability question, specifying the exact contents ('probability, confidence, and citations'). It also references the /answer/{slug} endpoint, which distinguishes it from sibling get_* tools that return forecasts, opinions, or market details.

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 phrase 'pre-computed answer card' and the reference to /answer/{slug} imply this tool is for retrieving already-generated answers rather than creating new ones. This provides clear context, though it does not explicitly name alternatives or exclusion criteria.

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

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

With no annotations, the description carries the full burden. It mentions the tool returns balance and portfolio value, indicating a read operation, but does not disclose any deeper behavior such as data freshness, aggregation scope, or potential caveats. For a simple getter this is adequate, but not rich.

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

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

The description is very short and front-loaded, but the leading 'Advanced:' prefix is unnecessary filler and does not add informative value. Otherwise, it is concise 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?

For a simple one-parameter tool with no output schema, the description provides the essential purpose. However, it does not describe the return structure or clarify how it differs from other portfolio-related tools, leaving gaps for an agent making a selection decision.

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 fully covers the only parameter (apiKey) with a description. The tool description adds no parameter-specific details, but the baseline of 3 applies because schema coverage is 100%.

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 specifies the resource (Kalshi account) and the data returned (balance and portfolio value), which is clear and goes beyond a tautology. However, it lacks a verb phrase and does not differentiate this from other portfolio-related sibling tools.

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

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

No guidance is given on when to use this tool versus alternatives like get_positions or portfolio_risk_get. There are no context signals or exclusions, leaving the agent to guess when this is the appropriate choice.

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 of behavioral disclosure. It states the content components but does not mention whether the tool has side effects, requires authentication, or what the response format looks like. For a read-style tool, this is a notable gap.

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

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

The description is a single, front-loaded sentence that conveys the tool's core purpose and content without wasted words. It is concise and efficiently 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 simple 2-parameter tool with no output schema, the description provides a complete picture of what the tool returns (narrative, markets, moves, dates) and its reusable nature. It lacks some details like window format, but overall it is sufficiently complete given the tool's simplicity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by linking the 'topic' parameter to the scoping and 'window' to 'prior moves' and 'key dates,' giving context beyond the terse schema descriptions. This enriches the semantic understanding of both parameters.

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

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

The description clearly identifies the tool as a 'Topic-scoped briefing' and specifies its contents: short narrative, relevant markets, prior moves, and key dates. This distinguishes it from other get_* tools like get_feed or get_highlights by emphasizing its topic-scoped nature and unique deliverable.

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 topic-specific briefings and mentions it is 'reusable as a callable /briefing card,' giving a concrete use case. However, it does not explicitly state when to prefer this over alternatives or provide exclusions, so guidance is mostly implicit.

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 disclosure burden. It accurately describes a read-only operation and lists return fields, which is basic transparency. However, it doesn't disclose potential side effects, rate limits, or nuances like how 'linked tickers' are derived or whether the calendar is manually curated versus automatically generated. The default lookahead is left to the schema, and no behavioral caveats are mentioned.

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

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

The description is two sentences, front-loaded with the core purpose, and includes examples to clarify scope. Every word earns its place; no wasted or redundant content. This is excellent conciseness.

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

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

For a simple tool with two optional parameters and no output schema, the description provides sufficient context: what it returns, what types of events, and category examples. It slightly misses an explicit statement about the default lookahead (though present in the schema) and clear differentiation from similar sibling tools, but these are minor gaps given the tool's simplicity.

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

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

Schema coverage is 100%: both 'days' and 'category' have descriptions in the schema. The description adds no new semantic detail beyond what the schema already provides. It mentions examples that align with the category filter but doesn't elaborate on value formats or constraints. Baseline 3 is appropriate when the schema carries the parameter load.

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: it returns upcoming dated events that drive prediction markets, with examples (FOMC, CPI, elections, sports). It specifies return fields (date, topic, linked tickers), giving a clear picture of the resource. However, it doesn't differentiate from the sibling tool 'get_schedule', which could serve a similar 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?

There is no guidance on when to use this tool versus alternatives like get_schedule, get_briefing, or get_milestones. The description implies use for market-moving events but doesn't state exclusions, prerequisites, or preference criteria. This leaves the agent without a clear selection rationale.

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 carry the burden of behavioral disclosure. It adds useful context by stating metrics are 'measured against resolved/settled markets', but it does not disclose potential side effects, cost, rate limits, or what 'drift alerts' entail. As a read-only getter, this is acceptable 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 a single, compact sentence that front-loads the domain and lists key metrics. It is efficient with no wasted words, though it could benefit from a clear sentence structure with a verb to improve readability.

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

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

For a simple read tool with two parameters and no output schema, the description gives a reasonable overview of the content but omits the return format and how parameters affect results. It also leaves domain terms like 'Brier scores' and 'edge bucket' undefined, which may be opaque to some agents.

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 (period and category). The description adds no additional parameter semantics, but the baseline of 3 applies since the schema handles the meaning 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 identifies the tool's domain as 'SimpleFunctions calibration' and lists specific outputs (Brier scores, hit rates, category breakdown, drift alerts), which distinguishes it from sibling tools. However, it lacks an explicit verb like 'returns' or 'retrieves', so the purpose is stated implicitly rather than directly.

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 no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It simply describes what the tool provides, leaving the agent to infer appropriate usage from the name and output list.

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 disclosing behavior. It mentions the event types and the 'since a timestamp' scoping, but it does not explicitly state that this is a read-only operation, describe pagination or rate limits, or explain behavior when no 'since' is provided. This leaves important operational details undisclosed.

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

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

The description is concise, with the first sentence front-loading the core functionality and event types, and the second giving usage context. It contains no unnecessary words, though the first sentence is a fragment rather than a complete sentence, slightly reducing structural polish.

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 relatively simple read tool with no output schema, the description covers the purpose and the types of changes, and gives usage context. However, it omits the return format, pagination behavior, and the optionality of the 'since' parameter, which are important for an agent to invoke it correctly. It is adequate but not fully fleshed out.

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

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

The input schema already documents all three parameters with descriptions, so the coverage is 100%. The description adds little beyond the schema; it restates the 'since' concept and lists event types that mirror the enum values. It does not clarify how parameters interact (e.g., q and type together), so it provides only marginal 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 identifies the resource as market change events and enumerates the three event types (new contracts, price moves, removed contracts), making the tool's focus specific. It also mentions intended use by the live feed and agent context refreshers, providing useful scope. However, it isn't a full sentence and doesn't explicitly distinguish from closely named siblings like get_changes_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 context ('Used by the live feed and agent context refreshers'), implying when to call this tool. However, it lacks explicit guidance on when not to use it or which alternative tools might be preferable, such as get_feed or get_changes_delta.

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 disclosing behavior. It explains the kind of information returned (signals consumed, edges updated, confidence moves), which is useful, but it does not explicitly state whether the operation is read-only, whether it supports pagination, or what happens when no changes exist. It adds some transparency but leaves 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 a single, front-loaded sentence that communicates the core purpose immediately and uses a compact list to enrich context. No word is wasted.

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 (3 parameters, no output schema, no annotations), the description adequately conveys the purpose and the nature of the returns. However, without an output schema, it would benefit from more detail on the exact return structure or pagination behavior to be fully complete. Still, for a simple delta tool, it provides a solid overview.

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 parameters. The description reinforces that 'since' is a timestamp lower bound and 'thesisId' is the per-thesis scope, but it adds minimal new detail 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 uses a specific verb ('get'), names the resource ('per-thesis change delta'), and clarifies the scope ('since a timestamp'). It also enumerates the types of changes (signals consumed, edges updated, confidence moves), which distinguishes it from siblings 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 implies the use case (tracking thesis evolution over time) but provides no explicit guidance on when to choose this tool over siblings like get_changes or get_world_delta, nor any exclusions or alternatives. It is adequate but lacks direct comparison.

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 full behavioral disclosure. It only states the action ('Get') and the input, without mentioning return format, potential errors, or any special behavior. For a simple read tool this is minimal but still lacks context that could help an agent anticipate outcomes.

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 containing only the essential information: action, resource, and identifier. It is concise, front-loaded, and free of 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?

The tool is simple with one parameter and no output schema, but the description does not explain what is returned or any prerequisites. Given the minimal complexity, the description is adequate but lacks completeness that could help an agent know what to expect after invocation.

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

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

The schema fully covers the single parameter 'id' with description 'Bioguide ID', and the description confirms this by saying 'by bioguide ID'. Since schema coverage is 100%, the description adds no new semantic information but reinforces the key concept, matching 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 tool gets a single Congress member by bioguide ID, using a specific verb and resource. It distinguishes from sibling tools like list_congress_members through the word 'single', though it does not 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?

Usage is implied: use this tool when you need a specific Congress member by bioguide ID. However, there is no explicit guidance on when to use this versus list_congress_members or other retrieval tools, and no exclusions are 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?

No annotations are provided, so the description carries the burden. It explains the conceptual behavior (co-movement and divergence) but does not disclose what the response contains, edge cases (e.g., no signals found), or any limitations. The description implies a read-only analysis tool but lacks explicit behavioral details like return format or pagination.

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-loaded with the key concept, and contains no fluff. Every word adds value, defining the signal type and the trading idea it surfaces. 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 of the contagion concept and the lack of an output schema, the description provides a good conceptual overview but does not specify the structure of results (e.g., list of market IDs with scores) or behavior under edge conditions. It is adequate but leaves room for more detail in a tool with no annotations or 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% for both parameters (topic and window), so the baseline is 3. The description does not add any parameter-level detail beyond what the schema already provides. It does not explain how they interact, but the schema descriptions are already sufficient for basic 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 function: it surfaces connected-market signals showing contracts that historically co-move with the input topic but have diverged in the current window. It uses a specific concept ('this market should have moved but didn't' trades) and differentiates from siblings like get_trade_ideas or scan_markets by focusing on divergence from historical co-movement.

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 a clear use case: finding divergent markets based on historical co-movement. It does not explicitly name alternatives or state when not to use it, but the 'this market should have moved but didn't' phrasing provides contextual guidance. Lacks explicit exclusions or alternative tool references, but sufficient for a straightforward signal 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 carries full burden. It discloses that data is live exchange data updated every 15 minutes, that the global context is rate-limited, and that API keys unlock higher limits. It also enumerates the delivered content. However, it does not explicitly state whether the operation is read-only (though 'snapshot' implies it) or describe possible error conditions.

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

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

Three sentences, each serving a distinct function: positioning ('START HERE'), content overview, and conditional usage. No filler or redundant phrasing.

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 snapshot tool with no output schema, the description covers the main contents, both modes, and rate-limit behavior. It does not specify response structure, but given the broad nature of the tool, the description is sufficiently complete for an initial selection decision.

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

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

Schema already documents both parameters (100% coverage). The description adds essential semantics: it explains that thesisId + apiKey together produce thesis-specific context, while omitting them yields the global snapshot on the free tier. This clarifies the dependency between parameters 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 provides a global market snapshot with specific content categories (top edges, price movers, highlights, traditional markets) and optionally thesis-specific context. The 'START HERE' prefix distinguishes it from sibling tools like get_edges or get_highlights.

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 positions the tool as the starting point ('START HERE') and clarifies when to use the global free tier vs thesis-specific mode (with thesisId + apiKey). It also notes rate limits and that API keys unlock higher limits, guiding 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?

With no annotations, the description carries the full burden. It discloses the data source (FRED), the types of outputs (latest values, percentiles, crosswalk), and the purpose. It does not explicitly state whether it is read-only, mention rate limits, or describe return format, but as a 'get' tool, the read-only nature is implied. This is adequate but not rich.

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

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

The description is a single, well-structured sentence that front-loads the main function (macro/economic anchors from FRED) and lists key outputs. Every word earns its place; no fluff 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?

The tool is simple with two fully described parameters and an output description that covers the main return elements. The description mentions the intended use case and data source, making it complete enough for an agent to understand and invoke. It does not describe return format, but with no output schema, the description gives a reasonable overview.

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 100% of parameters, each with a clear description (FRED series ID and category). The tool description adds no additional parameter-specific meaning beyond the schema. Following the baseline for full schema coverage, a 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 uses a specific verb ('get') with a clear resource ('Macro/economic anchors from FRED') and enumerates what it provides: latest values, percentile vs history, and crosswalk to prediction markets. This distinguishes it from sibling tools like query_econ or get_forecast by naming FRED and its unique output.

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 phrase 'For grounding macro theses' provides a clear context for when to use the tool. However, it does not explicitly mention alternatives or when not to use it. Given the context is clear but exclusions are absent, this aligns with a 4.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds meaningful context about auth behavior ('No auth = public thesis edges. Auth = private + public') and ranking by edge size. It does not disclose output format or pagination, but the core behavioral traits are covered.

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 concise sentences, front-loaded with the main purpose, and contains no fluff. The auth note is efficient and directly relevant.

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 relatively simple list tool with no output schema and 4 well-described parameters, the description is largely complete. It covers the core purpose, the ranking logic, and the auth distinction. It could arguably mention the return shape, but the description is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds minor context for the apiKey parameter by rephrasing the auth semantics, but otherwise it does not add meaning beyond what the schema already provides. This matches 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 identifies the tool's purpose: returning top mispriced markets across all theses, ranked by edge size, and showing where the model disagrees with the market. It uses specific concepts (edge size, theses) that help distinguish it from siblings like scan_markets or get_markets, though it does not name an alternative explicitly.

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

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

The description provides clear context about when to use the tool (to find mispriced markets) and clarifies auth-related behavior (public vs. private+public edges). However, it does not provide explicit guidance on when to choose this tool over related alternatives, nor does it state any 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?

With no annotations provided, the description carries full burden. It discloses that data is 'daily aggregated' and scoped to 'a thesis', which are useful behavioral details beyond the schema. It does not discuss response format or limitations, but for a read-only time-series tool, 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?

The description is two short segments, front-loaded with the core purpose ('Confidence trajectory over time') and immediately followed by usage guidance. 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?

Given only two parameters, no annotations, and no output schema, the description explains what the tool returns (daily aggregated confidence trajectory) and when to use it. It lacks explicit details about response structure, but the simplicity of the tool makes this a minor gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning to the parameters (thesisId, apiKey) beyond what the schema already states, so it neither exceeds nor falls below the baseline.

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

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

The description clearly states the tool returns a 'confidence trajectory' with 'daily aggregated evaluations for a thesis', specifying both the resource (thesis) and the data type (confidence over time). This distinguishes it from sibling history tools like get_market_history or get_index_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 phrase 'Use to analyze trends, detect convergence/divergence' provides explicit context for when to invoke this tool. However, it does not mention when not to use it or name alternative tools, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses the ordering and scope, but does not mention return format, pagination, or any safety characteristics. For a simple read operation, the info 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 short clauses that immediately convey the tool's purpose and key behavioral trait (ordering). Every word earns its place, with no filler or redundancy.

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

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

The tool is simple and has a complete schema with 100% parameter coverage. The description effectively communicates the core function and scope. It does not explain return values, but that is not required given the tool's simplicity.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no parameter-specific meaning beyond what the schema already provides, matching the baseline.

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

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

The description uses a specific verb ('get') with a clear resource ('feed') and explicitly states the scope ('every evaluation across all your theses') and ordering ('ordered descending'). This distinguishes it from sibling tools like get_evaluation_history, which likely targets a single 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 when to use the tool: when you need a cross-thesis evaluation feed. However, it does not explicitly mention alternatives or exclusion criteria, leaving the usage context somewhat implicit rather than fully explicit.

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

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

With no annotations, the description carries full transparency burden. It only states 'recent trade fills' without defining 'recent', whether auth is required (though schema shows apiKey), rate limits, or what data is returned. Minimal behavioral disclosure.

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

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

The description is extremely concise and front-loaded, but the one-liner lacks detail. The 'Advanced:' prefix adds little value. Still, it is efficiently 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 2-parameter tool with no output schema and no annotations, the description is too sparse. It fails to explain the concept of fills, time window, or relationship to other tools, making it incomplete for an agent to understand 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?

Input schema covers 100% of parameters with descriptions (apiKey and ticker), so baseline is 3. The description adds no parameter semantics 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 'Recent trade fills on Kalshi' clearly identifies the resource (trade fills) and scope (recent), with 'get' from the name implying retrieval. However, it does not differentiate from sibling tools like portfolio_fills_list or get_settlements, so it stops short of 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?

No usage guidance is provided. The description does not state when to use get_fills vs portfolio_fills_list or get_orders, nor any exclusion criteria. 'Advanced:' hints at a target audience but not use conditions.

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

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

With no annotations, the description carries the burden of disclosing behavior. It explains what the tool returns (percentile distribution over time) but does not explicitly state read-only nature, side effects, or rate limits. It adds some value beyond the schema by describing the output concept.

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 idea. The 'Advanced:' label is slightly unnecessary but does not undermine clarity.

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

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

Given the tool's moderate complexity and no output schema, the description sufficiently explains the high-level function. It does not detail return formatting, but the percentile distribution concept is clear enough for 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 a baseline of 3 applies. The description does not add semantic details for the parameters beyond what the schema already provides, but it does mention 'over time' which relates to the days 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 the tool provides P50/P75/P90 percentile distributions for a Kalshi event, which is a specific verb+resource combination. It distinguishes itself from sibling tools like get_market_history by focusing on percentile consensus shifts.

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 offers no explicit guidance on when to use this tool versus alternatives. The prefix 'Advanced' hints at a target audience but does not provide context for selection 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. It discloses that the tool returns 'full definition and links,' which is helpful, but it does not mention error behavior, read-only nature explicitly, or any other side effects. 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 a single sentence of 11 words, front-loading the core action ('Get a single glossary term') and adding useful detail about the return content. Every word earns its place, with no filler.

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 getter with one parameter, no annotations, and no output schema, the description is largely sufficient. It tells the agent what the tool does and what is returned, but could benefit from explicit note about when to choose this over `list_glossary` or how missing slugs are handled. Still, it is complete for most use cases.

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

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

The input schema has 100% coverage for the single parameter `slug`, with a description 'Glossary slug.' The tool description does not add additional meaning about the parameter, so it relies on the schema. No extra semantic context is 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 the tool retrieves a single glossary term, using the verb 'get' and specifying the resource. The word 'single' distinguishes it from the sibling `list_glossary` tool, making its 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 implies usage for fetching one specific term but does not explicitly mention alternatives like `list_glossary` for retrieving multiple terms. There is no direct when-to-use guidance or exclusions, only implied context.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure. It indicates a read operation through the verb 'Get' and notes the alias, but does not mention safety, permissions, rate limits, or any side effects, which is a notable gap for a tool with no structured safety hints.

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, compact sentence that immediately states the verb, resource, and scope, and includes the alias note without redundancy. Every word earns its place, and it is efficiently 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?

The tool is simple with only two parameters and no output schema, and the description covers its core purpose and alias relationship. However, it lacks any guidance on return format, usage context, or behavioral caveats, so it is adequate but not fully complete for an agent selecting and invoking the tool.

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

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

The input schema fully documents both parameters (apiKey and thesisId) with descriptions, so the description adds little beyond the schema. The phrase 'for a thesis' maps to the thesisId parameter but does not enrich parameter meaning further, matching the baseline of 3 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 identifies the tool's function: retrieving heartbeat configuration and monthly cost summary for a thesis. It also explicitly states it is an alias of get_heartbeat_status, distinguishing it from that sibling tool while clarifying its role.

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 alias note implies interchangeable use with get_heartbeat_status, but the description does not explicitly state when to choose this tool over alternatives. No exclusions or preferred contexts are provided, leaving usage guidance implicit.

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 the call returns configuration and cost data, and by naming the tool 'get' it implies a read-only operation, but it does not explicitly state the lack of side effects, authentication requirements, 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 a single, information-dense sentence. It front-loads the core purpose and includes specific details without wasting words.

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

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

With no output schema, the description adequately conveys what the tool returns (config, cost summary, scan intervals, model tier, budget usage). It is complete enough for a simple two-parameter GET tool, though it does not outline response format or potential edge cases like empty cost data.

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 apiKey and thesisId having descriptions. The description adds no extra meaning for parameters beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Get') and the resource ('heartbeat config + this month's cost summary for a thesis'). It lists specific content returned (scan intervals, model tier, budget usage), which distinguishes it from sibling get_heartbeat_config by adding the cost summary component.

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 you need heartbeat configuration and cost details, but it does not explicitly state when to use this versus get_heartbeat_config or configure_heartbeat. No exclusions or alternative guidance 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, what data source or freshness is used, or what happens when no highlights are available; it only names content categories.

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 short sentences with no filler. It front-loads the core purpose and uses examples to elaborate, making it highly scannable.

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

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

For a zero-parameter read tool the description is adequate, but without an output schema it leaves the response structure unstated. It does not clarify whether the result is a list, object, or aggregated summary, and does not mention any pagination or historical depth.

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

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

The tool has zero parameters, so the schema fully covers parameter semantics. The description does not need to add parameter detail; the baseline of 4 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 identifies the tool's output as daily editorial highlights with specific categories (top movers, divergences, contagion, resolved markets), making the purpose easy to grasp. However, it lacks an explicit verb and does not directly contrast with siblings like get_briefing or get_feed, so it stops short of full 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?

There is no guidance on when to use this tool versus the many similar get_* siblings, nor any mention of exclusions or prerequisites. The phrase 'for the day' implies a daily cadence, but this is not an explicit usage instruction.

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

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

Without annotations, the description discloses useful behavioral details: data is pre-computed every 15 minutes and stored since v2 launch (2026-04-09). This communicates freshness and availability bounds. It also describes the data as 'snapshots', implying point-in-time readings, which adds context beyond the 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?

Three short sentences covering resource, update cadence, data history start, and use case. No filler or redundancy.

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

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

For a tool with one optional parameter and no output schema, the description covers the core purpose, data timing, storage start, and intended use. It is sufficient, though it could explicitly mention that data is limited to the SimpleFunctions Index, which is already implied by the tool name and first sentence.

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

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

The only parameter 'days' is fully documented in the schema with type and default (7). The description adds no extra parameter-specific meaning, but the schema fully covers it, so a baseline score 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 identifies the resource as 'Historical SimpleFunctions Index snapshots', making it clear the tool retrieves historical index data. It distinguishes by naming the specific index, though it lacks an explicit verb or direct comparison to sibling history 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?

States the intended use case ('For charting trends'), providing implicit context for when to use it. However, it does not mention alternatives or exclusions relative to sibling tools like get_market_history or get_evaluation_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?

No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: the result includes a prediction-market cross-reference, and the alias relationship implies identical behavior to 'legislation.' However, it does not mention read-only status, permissions, or potential side effects, leaving much undisclosed.

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 entire description is a single, front-loaded sentence with no filler. It immediately states the action and resource, and the alias note adds useful context without redundancy.

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

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

For a low-complexity tool with one well-documented parameter and no nested objects, the description is adequate. It communicates the core function and a distinguishing feature (cross-reference), but the lack of an output schema means the agent may not know the exact return structure, though that is not strictly required.

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

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

The sole parameter, billId, is fully described in the schema with an example. The description's 'Get bill detail' adds no additional semantics beyond the schema, so the baseline 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 the tool retrieves bill details and augments with prediction-market cross-reference. It also notes it is an alias of 'legislation,' which helps distinguish it from other get_* tools, though the alias reference could be confusing to an agent deciding which canonical tool to use.

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

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

The description implies the tool is used to fetch a specific bill's details, and the alias note indicates it is interchangeable with the 'legislation' sibling. However, it does not explicitly state when to choose this over list_legislation or other bill-related tools, nor does it provide exclusions.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states that the tool returns raw JSON only and is lower-level, which adds context not in the schema. However, it does not disclose potential side effects (though 'get' implies read-only), permissions, error behavior, or output format details beyond the field list, so transparency is only partially covered.

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 only two sentences, front-loaded with the main action, and every word earns its place. It efficiently conveys purpose, scope, and differentiation 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?

For a simple retrieval tool with 100% schema coverage, the description is mostly complete. It lists the key content fields and offers a sibling comparison, but it omits mention of the 'depth' parameter (covered by schema) and does not describe what the 'history pointer' or 'cross-venue counterpart' actually return. Still, the tool is straightforward enough that the description is adequate.

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

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

The schema already provides 100% coverage for both parameters: 'ticker' is described as 'Market ticker' and 'depth' as 'Orderbook depth levels to include (0 = none)'. The description does not add any additional meaning to these parameters beyond the schema, so it relies on the structured schema as baseline.

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

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

The description clearly states the tool gets full detail for a single market and enumerates specific content (price, volume, indicators, regime label, history pointer, cross-venue counterpart). It also distinguishes itself from the sibling 'inspect_ticker' by noting it is lower-level, which helps differentiate from related 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 a clear context for when to use this tool: when raw JSON-level detail for a single market is needed, and explicitly contrasts it with the higher-level 'inspect_ticker'. However, it does not mention exclusions or alternative tools like 'get_markets' or 'get_market_history', so it is not fully explicit but still provides useful guidance.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses the core behavior (computing price/volume/indicator deltas vs a prior window) but does not state output format, default window behavior, or explicitly confirm the operation is read-only (though 'get' implies it). This is adequate but leaves room for more detail.

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 short sentences, front-loaded with the action and outcome. Every phrase adds value: the action, the comparison basis, the output dimensions, and a natural-language use case. No filler or redundancy.

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

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

The tool has 4 optional parameters and no output schema, so the description needs to stand in for return-value documentation. It does list the output dimensions and a use case, but it does not clarify how to specify the target market (tickers vs topic) or how window/sort affect the results. This is a moderate gap for a tool of this complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds contextual phrasing like 'prior window' and a use case, but it does not explain how tickers, topic, window, and sort interact or which combinations are valid. The schema descriptions themselves are the main source of parameter 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 uses a specific verb 'Diff' and a specific resource 'a market vs the prior window', and enumerates concrete outputs (price delta, volume delta, indicator drift). This clearly distinguishes it from related tools like get_market_history or get_market_detail, which focus on absolute values rather than deltas.

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 an explicit trigger example: 'For "what changed in the last 6h?" questions.' This gives clear context for when the tool is appropriate. It does not mention alternatives or exclusions, but the use case is strong enough to guide an agent.

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

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

With no annotations, the description carries the full burden. It discloses the rolling 7-day window, price+indicator content, and single-market scope, which is useful. However, it does not mention any caveats like whether the history is adjusted, whether it returns empty for new markets, or any rate limits. For a read-only get tool, this is adequate but not rich.

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

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

The description is two short sentences, front-loaded with the key function and scope. Every word earns its place, and there is no redundant information. It is efficiently 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 simple single-parameter get tool with no output schema, the description adequately communicates what data will be returned (price+indicator history over 7 days). It doesn't need to detail the output structure since the tool name and usage context imply a time-series response. Could mention indicator names but not required for 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 already provides 100% coverage with a clear description for the only parameter (ticker: 'Market ticker'). The tool description adds no new parameter details beyond what the schema offers. Baseline 3 is appropriate since 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 rolling 7-day price and indicator history for a single market, which is specific and distinguishes it from sibling tools like get_market_detail or get_market_diff. It uses the verb 'Get' with a precise resource and scope. Could be a 5 if it explicitly named a sibling or further differentiated from get_technical, but it's already clear.

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

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

The phrase 'For trajectory questions and chart rendering' gives a clear usage context. This helps an agent decide when to use this tool (e.g., when needing time-series data for a chart). It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by specifying the four gauges, their value ranges, and the 15-minute update frequency, which helps the agent anticipate the data's freshness and structure. It does not mention any side effects or safety implications, but for a read-only index this is sufficient.

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

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

The description is extremely concise, using only two sentences to convey the tool's purpose, components, and update cadence. It is front-loaded with the index name and immediately lists the gauges, with no unnecessary words.

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

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

For a simple no-parameter read-only tool, the description is fairly complete: it names the gauges, gives their ranges, and states the update interval. It lacks an explicit return format or example, but given the simplicity and absence of an output schema, the description adequately covers what the agent needs to know to invoke and interpret the tool.

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

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

The tool has zero parameters, so the input schema provides no information. The description appropriately lists the output components, but parameter semantics are trivially satisfied since no parameters exist. The baseline of 4 applies for zero-parameter tools.

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

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

The description clearly identifies the tool as a prediction market index with four specific gauges and their ranges. It is not a tautology and does not mislead, though it lacks an explicit verb like 'returns' and does not differentiate from sibling tools that might also provide market-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 gives no guidance on when to use this tool versus alternatives such as get_index_history or get_market_detail. It does not state whether it should be used for current snapshots or historical analysis, so the agent is left without explicit 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, so the description must disclose behavioral traits. It lists output fields but does not discuss operational details such as read-only guarantees, data availability, sorting, or response structure. This is a notable gap 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 long, front-loaded with the core data content, and every word adds value. It is concise without sacrificing essential 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?

Despite lacking an output schema and annotations, the description provides field names and a use case, which is helpful for an agent. However, acronyms like CRI, EE, and LAS are not expanded, and the return structure is not detailed, preventing a higher score.

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 description adds little beyond the schema. It lists output fields, but these are not parameters. The parameters (ticker, days, interval) are already well-described in 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 identifies the tool as providing a per-ticker microstructure time series, listing specific fields (implicit yield, CRI, EE, LAS, overround, realised volatility) and the use case of charting indicator drift. This distinguishes it from generic market history 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 explicitly states a use case ('Used for charting indicator drift'), which gives clear context for when to use the tool. However, it does not mention alternative tools or exclusions, so it falls short of explicit 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, the description must carry the behavioral burden. It states the data source (Databento), the default symbols, and the topic categories, which provides useful context. However, it does not disclose output format, update frequency, or any limitations, leaving the agent to infer the exact behavior of 'market prices'.

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

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

The description is two sentences, front-loaded with the core action, and every word adds value. The first sentence states the function and default universe; the second efficiently enumerates topic options and their coverage. No fluff or repetition exists.

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 low complexity (one optional parameter, no output schema), the description is largely sufficient for an agent to invoke it correctly. It covers defaults, topic choices, and data source. It could be slightly more complete by describing the shape of the returned prices, but this is not critical for a simple fetch tool.

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

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

The schema already documents the single parameter 'topic' at 100% coverage, so the baseline is 3. The description adds significant value by enumerating accepted topic values and mapping each to concrete instruments (e.g., energy → WTI, Brent, NG, Heating Oil), which goes beyond the schema's generic 'Deep dive topic' phrasing.

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

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

The description uses a specific verb ('Get') with a clear resource ('traditional market prices via Databento') and defines the default scope (SPY, VIX, TLT, GLD, USO). It distinguishes itself from sibling tools by emphasizing a broad default snapshot plus deep-dive topics, making the tool's purpose unmistakable.

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

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

The description clearly states when to use the tool (for traditional market prices) and how to use the optional topic parameter for deep dives in specific asset classes. It does not explicitly name alternatives or exclusions, but the detailed topic mapping gives practical 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?

With no annotations provided, the description carries the full burden. It discloses that the tool is free-tier and rate-limited, which is useful context. However, it does not describe the return format, pagination, or any other behavioral traits that might affect usage, leaving significant gaps for a data-fetching 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 two short sentences, each adding value: one describes the purpose, the other provides practical constraints. No redundant or extraneous information is present.

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 two optional parameters and no output schema. The description adequately conveys the main purpose and a key constraint (rate limiting), but could be more complete by briefly noting the return structure or what 'milestones' entails. Overall, it is sufficient for basic understanding.

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

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

Schema description coverage is 100%, with both 'hours' and 'category' already documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool gets upcoming events from the Kalshi calendar, naming specific event types (economic releases, political events, catalysts). It uses a specific verb+resource construction, but does not differentiate from sibling tools like get_calendar or get_schedule.

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

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

The description implies the tool is for retrieving upcoming events, and the mention of 'Free-tier and rate-limited' suggests it is suitable for lightweight queries. However, it does not provide explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

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

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

Without annotations, the description carries the full burden of behavioral disclosure. It tells what the tool returns (recently-listed markets) but does not disclose important traits such as whether results are combined across venues, how 'recently' is defined, ordering, pagination, authentication needs, or any limitations. This is a significant gap for a retrieval 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—two brief clauses that immediately convey the core purpose. There is no wasted wording, and the most important information (what the tool returns) is front-loaded. It exemplifies efficient, targeted writing.

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 there is no output schema and no annotations, the description should explain what the returned market data looks like (e.g., symbols, prices, liquidity fields) to enable correct invocation. It does not, and it also omits any detail about how the venue and lookback parameters affect the results. While the schema covers parameter names, the overall description leaves too much unspecified for a tool with four optional parameters.

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 all four parameters (hours, limit, venue, minLiquidity) are already documented. The description adds no extra parameter-level context beyond the generic 'fresh' opportunity framing, so the 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 specifies the resource (recently-listed markets, new contracts) and the venue scope (Kalshi and Polymarket), which distinguishes it from sibling tools like get_markets. However, it lacks an explicit verb like 'list' or 'returns'; the action is implied by the tool name and the noun phrase structure.

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 phrase 'For finding fresh trading opportunities' implies a use case, giving some context for when to use the tool. Yet it provides no explicit guidance on when to use it over alternatives (e.g., get_markets, scan_markets) nor any 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and does not mention return format, error behavior, authentication needs, or what happens if the slug is not found. This is insufficient for a tool with zero annotation support.

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, focused sentence that front-loads the core action and resource. There is no wasted wording, and it is appropriately sized for the tool's simplicity.

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 one parameter and no output schema. The description explains the basic purpose but does not clarify what the returned opinion/essay looks like or any edge cases. Given the low complexity and the existence of sibling list_opinions, the description is minimally adequate but not richly informative.

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 'slug' described as 'Opinion slug'. The description adds 'by slug' but does not provide any additional semantic meaning beyond what the schema already offers. The baseline of 3 is appropriate since the schema handles the 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 verb 'Get' and the specific resource 'single opinion/essay by slug', which distinguishes it from sibling list_opinions. It is precise and leaves no ambiguity about what the tool does.

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

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

The usage context is implied: use this tool when you have a slug and need one specific opinion. However, there is no explicit guidance on when to prefer this over list_opinions or any alternatives, nor any exclusions mentioned.

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

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

With no annotations, the description carries the full burden but only states that the tool returns current resting orders. It omits behavioral details like auth requirements, pagination, data freshness, or error handling, offering minimal 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 brief and front-loaded, conveying the core idea in a few words. The 'Advanced:' prefix is somewhat unnecessary, but the overall structure is efficient.

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

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

Given a simple 2-parameter tool with no output schema or annotations, the description is minimally adequate. However, it leaves uncertainty about response structure and does not leverage context to clarify usage, so it falls short of full 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 already provides 100% coverage, explaining both apiKey and status with defaults and allowed values. The description adds no additional parameter semantics, so a 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 specifies the tool retrieves current resting orders on Kalshi. The phrase 'resting orders' distinguishes it from executed or canceled order queries, aligning well with sibling tools like get_fills.

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 about when to use this tool versus alternatives such as get_fills or get_positions. It does not mention exclusions, prerequisites, or appropriate contexts beyond the terse 'Advanced' label.

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 transparency burden. It explicitly states 'reads the broker side,' disclosing that this is a read-only operation. It also adds context about 'live P&L' and contrasts with per-thesis records. It does not detail rate limits, error behavior, or output structure, but the read-only nature is clearly transmitted.

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 filler. It front-loads the purpose ('Advanced: Open Kalshi positions with live P&L') and then provides a clear distinction from sibling tools. 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 tool with one parameter and no output schema, the description covers the core purpose and relationship to siblings. However, given the presence of portfolio_positions_list in the sibling list, a brief clarification of how this differs from that tool would have made it fully complete. Still, the description is sufficiently clear for an agent to select it.

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

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

Schema description coverage is 100%, so the schema already fully documents the single parameter 'apiKey' with its purpose and setup requirement. The description adds no additional meaning beyond what the schema provides, 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 the tool reads open Kalshi positions with live P&L, using the verb 'reads' and specifying the resource as 'Kalshi positions' and 'broker side.' It also distinguishes itself from sibling mutation tools (add_position/close_position/update_position) by explicitly calling itself the read counterpart.

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 context on when to use this tool versus the mutating position tools: 'Counterpart to add_position/close_position/update_position which mutate per-thesis position records — this reads the broker side.' However, it does not mention other potentially overlapping read tools like portfolio_positions_list, leaving a gap in alternatives.

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

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

No annotations are provided, so the description carries the full burden. It states the tool retrieves a single published skill, but does not disclose what happens if the slug does not exist, whether unpublished skills are accessible, authentication requirements, or the response format. This is minimal behavioral disclosure for a getter.

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 of six words, immediately front-loads the action (Get) and key qualifiers (single, published, by slug). Every word earns its place; there is no waste.

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

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

For a simple 1-parameter, no-output-schema getter, the description is largely sufficient: it names the operation, the resource, the qualifier (published), and the lookup mechanism. It could be more complete by noting error behavior, but the low complexity means the description is adequate for selection and invocation.

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

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

The input schema has one parameter 'slug' with the description 'Public skill slug', and schema description coverage is 100%. The tool description adds no new semantic detail about the parameter beyond what the schema already provides, so the 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 uses a specific verb ('Get'), identifies the resource ('a single published skill'), and specifies the lookup key ('by slug'). This clearly distinguishes it from siblings like browse_public_skills or list_skills, which imply listing/exploration.

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?

Usage is implied through the phrase 'single published skill by slug': use this when you have a specific slug and want one published skill. However, there is no explicit guidance on when not to use it (e.g., when browsing or listing skills) or alternatives, so guidance is only 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 provided, the description carries full behavioral burden. It only states the action without disclosing output format, defaults, or side effects. The tool is likely a read-only scan, but that isn't stated, and 'optional indicator filters' is ambiguous.

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-loads the core action, and avoids fluff. Every sentence contributes meaning.

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

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

The tool has 7 optional parameters but no annotations and no output schema. The description covers the main purpose but omits details like default limit, sort behavior, and what 'indicator filters' actually maps to. For a scan tool, the lack of return format or usage examples makes it less 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%, providing descriptions for all 7 parameters. The description adds the specific regime labels enumeration (bull, bear, range, frontier, panic) beyond what the schema's 'Regime label filter' says. However, 'indicator filters' is vague and doesn't clearly map to schema properties like hasEdge.

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

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

The description clearly states the tool scans markets by regime label, listing the specific labels (bull, bear, range, frontier, panic). It distinguishes the tool from generic scanners like scan_markets by emphasizing regime-based screening.

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 phrase 'For regime-based screening' provides clear context for when to use it. However, it doesn't explicitly name alternatives or exclusions, so it falls short of a 5.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure, but it only states the basic action. It does not explain the nature of the returned data, any potential side effects (though likely none), or output format. The minimum is met but little added 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 that states the tool's purpose without any fluff or repetition. Every word contributes to the meaning.

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

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

For a no-parameter tool with no output schema and no annotations, the description is minimal but leaves ambiguity about what 'exchange status' includes (e.g., open/closed, holidays, delayed openings). It is adequate but not rich.

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 zero parameters, so the description does not need to explain parameter meanings. Per rubric, a baseline of 4 applies when there are no parameters, and the description provides no conflicting or additional parameter information.

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

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

The description clearly states the tool's function with a specific verb ('Get') and resource ('exchange status and trading hours'). It is distinct from all sibling tools, none of which explicitly mention schedule or exchange status.

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. The description only states what it does, with no mention of use cases, 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 only states the data returned ('settled contracts with realized P&L') but does not disclose whether this is a read-only operation, what authentication beyond apiKey is needed, whether pagination exists, or how results are structured. This is a significant gap for a financial data 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, at one sentence, and is front-loaded with the 'Advanced' label. Every word except 'Advanced' contributes meaning, and there is no unnecessary repetition. It could be more informative without sacrificing conciseness, but it is not bloated.

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

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

The tool has no output schema and no annotations, so the description must explain what the tool returns and how to use it. It gives only a high-level phrase and does not mention return format, ticker filtering semantics, or relationship to sibling tools. For an 'Advanced' tool with this little context, the description is insufficient.

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

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

Schema description coverage is 100%, with apiKey and ticker both documented in the input schema. The description does not add any parameter-level meaning, but the schema already clearly explains both parameters, so the baseline of 3 is appropriate.

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

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

The description names a specific resource—settled contracts—and identifies the key output as realized P&L, which distinguishes it from related tools like get_fills and get_positions. The verb is implied by the tool name ('get') rather than stated in the description, and 'Advanced' adds little, but the core purpose is clear.

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

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

No guidance is provided about when to use this tool versus alternatives such as get_fills, get_orders, or get_positions. The 'Advanced' label hints at complexity but does not state use cases, prerequisites, or exclusions, leaving the agent to guess when this tool is appropriate.

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 adds the scope 'authenticated user's' which clarifies it operates on the user's own skills, but does not disclose output shape, pagination, or any other behavioral details. For a simple 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 a single sentence plus a parenthetical alternative, front-loaded with the main action. Every word serves a purpose, with no redundancy or filler.

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 with no output schema, the description adequately conveys the primary purpose and scope. It could mention the return format or skill object structure, but the simplicity of the tool makes the current description 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?

The schema already documents the only parameter (apiKey) with 100% coverage, so the description does not need to add parameter details. The description adds no additional meaning beyond the schema, matching the baseline for full schema coverage.

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

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

The description clearly states the verb 'List' and the resource 'authenticated user's skills', providing a specific scope. It also distinguishes from browse_public_skills by noting public skills are handled there, helping differentiate among siblings.

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

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

The parenthetical 'Public skills are at browse_public_skills' explicitly directs users to an alternative tool for public skills, making the intended use case clear. This effectively communicates when to use this tool versus a sibling.

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

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

With no annotations, the description carries full burden for behavioral transparency. It only says it gets a doc by slug, disclosing nothing about return format, error handling, permissions, or whether this is a read-only operation (though the 'get' name hints at it). This is minimal disclosure.

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

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

The description is a single, concise sentence with no fluff. Every word contributes to the purpose, making it highly efficient 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?

For a simple one-parameter tool, the description is adequate but not complete. It fails to explain what a technical reference doc is or how it relates to sibling tools like list_technicals, and it does not describe error behavior. More context would improve completeness.

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

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

The input schema already describes the slug parameter with 100% coverage, so the description adds little beyond repeating 'by slug.' It does not clarify slug format, case sensitivity, or how to obtain a valid slug, but the schema baseline of 3 is appropriate.

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

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

The description clearly states the verb ('get'), the resource ('technical reference doc'), and the retrieval method ('by slug'). It distinguishes this from list_technicals by emphasizing 'single,' though the exact nature of a 'technical reference doc' is not elaborated.

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 instead of other get_* tools or list_technicals. The description gives no context about prerequisites, alternatives, or common use cases, leaving the agent to infer 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?

With no annotations, the description carries the full burden. It discloses 'Auth-only' as a security trait and lists the content components, but does not mention read-only behavior, error conditions, response format, or pagination. It adds some context beyond the schema but lacks deeper behavioral depth.

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

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

Two sentences, front-loaded with the main purpose, no wasted words. The second sentence efficiently provides a usage alternative.

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 2-param tool with no output schema, the description adequately conveys the return content categories (causal tree, edges, evaluation history, track record) and provides an alternative path. It could be more explicit about output structure or response details, but given the tool's simplicity, it is fairly complete.

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

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

Schema coverage is 100%, with both apiKey and thesisId having basic descriptions. The description adds minimal meaning beyond implying thesisId identifies the thesis and mentioning the alternative get_context call. It does not elaborate on 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 states the tool retrieves thesis-specific context including causal tree, edges with orderbook depth, evaluation history, and track record. This specific verb+resource clearly differentiates it from sibling tools like get_context and get_edges.

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

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

It explicitly directs users to use get_context without thesisId for the global market snapshot, providing an alternative for a distinct scenario. However, it does not mention exclusions for other related get_* tools beyond get_context, so it is clear but not exhaustive.

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 recommendations are synthesized from live market data, edges, and macro context, and that ideas include conviction level, catalyst timing, direction, and risk. It also mentions rate-limiting, which is a behavioral trait beyond the base functionality.

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

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

The description is two sentences, front-loaded with the core purpose and immediately followed by valuable usage context. Every phrase earns its place, including the output attributes and the rate-limit warning. 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?

For a tool with no output schema and no annotations, the description provides a solid overview: purpose, output characteristics, and usage directive. It could specify return format or pagination, but the mention of conviction level, catalyst timing, direction, and risk gives a good sense of what to expect. Overall, it is sufficiently complete for a list-type tool.

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

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

The input schema already describes all three parameters (limit, category, freshness) with 100% coverage. The description does not add any additional meaning to these parameters, but it doesn't need to since the schema is self-explanatory. The description focuses on the output rather than parameter usage, 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 identifies the tool as providing "S&T-style trade recommendations" and "actionable pitches," which is a specific verb-resource pairing. It distinguishes itself from sibling tools by emphasizing trade ideas specifically, and the directive "START HERE" reinforces its unique role.

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 "START HERE when looking for what to trade," giving clear guidance on when to use this tool. It also notes free-tier and rate-limiting, which helps set expectations. However, it does not mention when not to use it or point to specific 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, the description must convey behavioral traits. It mentions the incremental nature and token efficiency (~30-50 vs 800), which is useful. However, it does not disclose whether the operation is read-only, what happens when no changes exist, or the response structure beyond the format parameter in the schema. It provides some context but not comprehensive behavioral disclosure.

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

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

The description is exceptionally concise, consisting of three short clauses that immediately establish purpose, efficiency, and use case. Every word earns its place, and it is properly front-loaded with the core concept.

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

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

Given a simple 2-parameter tool with no output schema, the description covers purpose, usage, and efficiency. The format parameter (markdown/json) gives some hint about return structure, but the description does not mention potential responses when there are no changes or clarify the exact content. Still, it is largely complete for the tool's simplicity.

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

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

Schema description coverage is 100% for both parameters ('since' and 'format'). The description only repeats the 'since a timestamp' idea from the schema and adds no additional meaning about parameter syntax, default behavior, or dependencies. 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 provides an incremental world state update, explicitly framing it as a delta since a timestamp. This distinguishes it from siblings like get_world_state and other delta tools. The verb 'update' is slightly off (it retrieves an update), but the meaning is unambiguous.

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

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

The description provides a clear usage context: 'For periodic refresh during long tasks.' It also implies an alternative by comparing token counts to 'full state,' but does not explicitly name a tool like get_world_state. This makes the guidance clear but not fully explicit.

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

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

With no annotations, the description carries the full burden. It discloses real-timeness, token budget (~800 tokens), content scope, and auth requirements—useful behavioral context. However, it does not explicitly state that the operation is read-only or side-effect-free, and it omits details like rate limits or error behavior. This is moderate but not exceptional 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 two sentences and roughly 50 words, front-loaded with the core purpose. Every sentence adds value: the world model concept, token budget, covered topics, anchor contracts, and auth note. No wasted words or repetition.

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

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

No output schema exists, but the description gives a good sense of the response content: ~800 tokens, specific topic coverage, and always-present anchor contracts. It does not describe pagination or detailed error handling, but for a simple snapshot tool with two optional parameters, it is fairly complete.

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

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

Schema coverage is 100%, meaning the schema already documents both parameters (focus and format) with descriptions. The tool description adds no additional parameter meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description clearly states it provides a real-time world model covering specific topics (geopolitics, economy, energy, etc.) with prediction market probabilities. The verb+resource is clear, but it does not explicitly differentiate from sibling tools like get_briefing or get_world_delta, so it falls short of 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 implies usage (when an agent needs a compact world state snapshot) and notes 'No auth needed', but it does not explicitly state when to use this tool versus alternatives or mention exclusions. No sibling tools are referenced, so guidance is only implicit.

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 merely restates what the tool does without adding any behavioral context. With no annotations provided, the description carries the full burden of disclosing side effects, data freshness, or other traits, but it discloses none. An agent cannot tell if this is read-only (though 'get' implies it), whether it returns historical data, or if any special conditions apply.

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, consisting of a single short phrase. It is front-loaded and has no wasted words. However, it is so terse that it borders on under-specification; still, for a simple read operation, the brevity is acceptable 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 a well-described schema, but the description is too minimal to be complete. It does not clarify what constitutes an 'event series' beyond the schema example, nor does it explain how this tool relates to the sibling get_yield_curves. With no output schema or annotations, the agent has little guidance on expected return shape or edge cases, making this less than minimally viable.

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