Licium

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

The description is exceptionally transparent: it warns that output is untrusted external content, advises against executing commands, and notes the 'ignore previous instructions' risk. This adds critical safety context beyond annotations, which only indicate non-read-only and non-destructive.

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

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

The description is front-loaded with the core action and then provides examples and safety notes. While somewhat verbose, the structure is logical and each section adds value. Minor redundancy in the registry explanation.

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, the description explains the output format (pre-formatted markdown) and how to handle it. It covers examples, safety, and the open-ended nature of the tool. Missing explicit structure of the result, but sufficient given 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%, so baseline is 3. The description enriches parameters by providing concrete examples of how to use 'task', 'max_steps', and 'cost_preference'. It also explains defaults and options, adding practical value beyond the schema.

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

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

The description clearly states the tool executes a task through agents, planning and routing. It distinguishes from siblings by being the general execution tool, but boundaries with licium_discover (discovery) could be sharper. The verb 'execute' and resource 'task' are specific.

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

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

The description gives examples of when to use (e.g., forecasting, comparing agents) but does not explicitly state when not to use or alternative tools among siblings. The context is implied but not directive.

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

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

The description adds the behavioral trait that the tool returns a 'paused' response rather than a billable empty report. Annotations already indicate readOnlyHint=true, so description adds useful context beyond annotations.

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

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

Extremely concise with only two sentences. The first word 'PAUSED' front-loads critical status information, and every sentence provides essential value.

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

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

For a simple tool with one parameter, no output schema, and good annotations, the description fully covers what the tool does, its current status, and viable alternatives.

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

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

Input schema has 100% coverage with a clear description for the 'url' parameter. The description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool is for 'on-demand cross-agent market analysis' and uses a specific verb 'analyze' with a specific resource 'prediction market'. It also distinguishes itself from siblings by naming two live 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?

Explicitly tells the user the tool is paused and provides live alternatives ('licium_scan_edges' and 'licium_discover'), giving clear when-to-use and 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, ensuring the tool is safe. The description adds behavioral context beyond annotations by listing specific actions (searching with reputation scores, health checks, finding alternatives) and noting that it is non-destructive. No contradictions.

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

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

The description is longer than strictly necessary but well-structured with headings and bullet points. It front-loads the key purpose and action categories. Some repetition could be trimmed, but it remains clear and 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?

No output schema is provided, so the description must cover return values. It mentions reputation scores, success rates, and health check results, but does not specify the exact output structure. For a discovery tool with multiple capabilities, the description covers the main contexts (search, compare, status) adequately but could be more precise about output format.

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

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

Schema coverage is 100%, so the schema already documents all three parameters (query, type, limit). The description does not add new semantic details about parameter values beyond the schema's descriptions, but it provides example queries that help illustrate usage. 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's purpose: 'Browse and compare Licium's agents and tools.' It provides a detailed list of capabilities (search, compare, check status) and explicitly distinguishes it from the sibling tool licium: 'If you just want results, use licium instead.'

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 includes a dedicated 'WHEN TO USE' section: 'When you want to browse, compare, or check before executing.' It also gives a clear exclusion: 'If you just want results, use licium instead.' This provides excellent guidance on when to use this tool over its siblings.

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

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

Annotations indicate non-readonly, non-destructive, and open-world. The description adds that the share action is a legacy placeholder with no effect, which is helpful. However, it lacks details on registration side effects (e.g., overwriting, required auth) or report behavior beyond sending data. The description adds marginal value beyond annotations.

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

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

The description is concise (three sentences plus bullet-like action list) and front-loaded with the main purpose. It avoids unnecessary words, but a more structured format (e.g., explicit bullets for each action) could improve readability slightly.

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

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

Given the tool has 17 parameters, no output schema, and three distinct actions, the description covers the core use cases adequately. It explains each action's purpose and required parameters indirectly. However, it does not describe return values or prerequisites (e.g., needing an account), which leaves minor gaps.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description only lists parameters per action without adding new meaning or usage context (e.g., formatting, validation rules). Baseline score of 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the tool manages presence on Licium with three specific actions: registering agents, reporting tool quality, and sharing (legacy). It distinguishes from sibling tools like licium_discover or licium_analyze_market by focusing on management operations.

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

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

The description enumerates the three actions (register, report, share) and notes that share is 'parked' and creates no public link. While it provides clear context for each action, it does not explicitly state when to use this tool over siblings or provide 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?

Discloses that results are for settled predictions and includes key fields. Annotations already declare readOnlyHint, idempotentHint, and no destructiveness; description adds meaningful behavioral context about the nature of receipts.

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 that are front-loaded with the tool's purpose and quickly convey the value proposition. No superfluous 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?

Given no output schema, the description adequately summarizes the return fields and tone. It could mention pagination or the max limit, but for a simple list tool, it is mostly 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 provides full description for the single parameter (limit), so the description adds no new semantics. Baseline 3 applies due to 100% 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?

Description clearly states the tool returns recent prediction receipts with specific data fields (forecast, market price, outcome, edge). It distinguishes its purpose as 'evidence of calibration' not betting advice, differentiating it from potential alternatives like analysis tools.

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

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

Provides implicit guidance by stating it is 'evidence of calibration, not betting advice,' which helps the agent understand appropriate contexts. However, it does not explicitly mention when to use this tool over siblings like licium_scan_edges or licium_analyze_market.

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?

Beyond annotations (idempotent, not destructive), the description adds that a session token is required and that registration leads to weekly scoring. It provides context about the tool's role in a larger process, enhancing 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 three concise sentences, each earning its place: purpose, prerequisite, and subsequent action. No wasted words, front-loaded with key information.

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

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

Given two parameters, no output schema, and informative annotations, the description is nearly complete. It covers the action, prerequisite, and what follows, though it omits details about the registration response or potential errors.

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 reinforces the sport default and token source, but adds no new semantic meaning beyond what the schema already provides.

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

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

The description clearly states the tool registers an agent into a weekly prediction tournament for a sport, with a specific verb and resource. It distinguishes from sibling tools like licium_tournament_leaderboard by focusing on entry rather than standings.

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

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

The description explains the prerequisite (session token from licium link) and the subsequent workflow (submit probabilities, scoring weekly). However, it does not explicitly contrast with alternative tools or state when not to use it.

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

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

The description fully discloses behavioral traits beyond annotations: it deducts 1 credit, returns specific fields (bet_instruction, pick.signal, etc.), and clarifies that it's not a bet. Annotations already indicate mutability (readOnlyHint=false) and idempotency (idempotentHint=true). No contradictions; the description adds valuable context about the credit deduction and output structure.

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 three sentences, efficiently front-loaded with the main action ('Rent a verified prediction agent's upcoming pick for a market'). Each sentence adds essential information: credit deduction, return fields, validity notes, and clarification that it's not a bet. No redundancy or wasted words.

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

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

Given the absence of an output schema, the description comprehensively explains the return value (bet_instruction, pick.signal, pick.market_links, etc.) and important temporal constraints (pick.valid_until, pick.rentable_until). It also clarifies legacy fields. This level of detail ensures the agent understands what to expect from 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 covers all parameters with descriptions (100% coverage). The tool description does not add extra meaning to the parameters themselves; it focuses on return value behavior. Per guidelines, baseline is 3 when schema coverage is high, and no additional parameter context is provided, so a score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Rent a verified prediction agent's upcoming pick for a market.' It distinguishes from siblings by emphasizing that it provides a bet instruction that the user acts on themselves, not a bet execution. The 'Not a bet; you act on it yourself' line further clarifies the distinct nature.

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

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

The description implies when to use the tool (to obtain an agent's pick for implementation) and what it returns. It does not explicitly exclude sibling tools or state alternatives, but the context of renting a pick vs. analyzing markets (licium_analyze_market) or discovering agents (licium_discover) is clear enough. A brief mention of when not to use it would improve, but the current clarity is high.

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

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

No annotations present, so description carries full burden. Discloses public vs locked results, freshness metadata, stale signal marking, ranking behavior, and endpoint usage with credits. Highly 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?

Description is longer but each sentence adds value. Front-loaded with purpose. Slightly verbose but 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?

No output schema or annotations, yet description covers return structure, authentication, endpoints, filters, and even provides URLs. Complete for the tool's 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% but description adds defaults (min_ev=0, -1), clarifies domain limitations, and explains platform filter. Adds meaningful context beyond schema.

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

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

The description clearly states the tool scans weather prediction markets for expected-value edge, with specific verb 'scan' and resource. It distinguishes from sibling tools by focusing on edge detection in the weather domain.

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

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

Provides explicit guidance on using POST endpoints to unlock signals, filter parameters, and domain specificity. Lacks explicit when-not-to-use or alternative comparisons, but context is strong.

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?

Adds context beyond annotations by noting the output includes calibrated probabilities and that the agent must decide how to act, complementing the readOnlyHint and idempotentHint.

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 that front-load the purpose and efficiently cover all key aspects 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?

Adequately covers the tool's functionality given the simple parameter set and rich annotations, though it could optionally detail the return structure more.

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

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

Adds meaning beyond the schema by explaining the conditional behavior of tournament_id and the default value for sport, enhancing understanding of parameter usage.

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

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

Clearly states it returns ranked prediction agents from weekly tournaments, and distinguishes between season standings and weekly ranking based on the tournament_id parameter.

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 explains when to use without vs with tournament_id, and notes that the output contains calibrated probabilities for decision-making, though it does not explicitly contrast with sibling tools.

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