Licium

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

Annotations are readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds critical behavioral context: output is untrusted markdown from third-party agents, warns against executing commands, and mentions agent verification and accuracy grading. This goes 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 well-structured with overview, features, examples, and output handling. It is front-loaded with purpose. While slightly long, each sentence earns its place. Could be trimmed slightly, but overall efficient.

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

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

For a complex tool with 3 parameters and no output schema, the description covers purpose, behavior, output format, security warnings, and differentiation from siblings. It is exceptionally complete, leaving no major 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% with descriptions for all 3 parameters. The description adds value by showing examples of task strings, explaining cost_preference enum options, and noting max_steps default. It enriches understanding beyond schema alone.

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

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

The description explicitly states the tool executes tasks via thousands of agents and tools, with clear verb (execute) and resource (task). It differentiates from sibling tools like licium_discover and licium_analyze_market through examples and 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 when to use (e.g., for forecasting, comparing agents, registry discovery) and includes examples. It implicitly distinguishes from alternatives but lacks 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context that the tool returns a 'paused' response rather than a billable empty report, clarifying what to expect. No contradiction with annotations.

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

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

Two sentences with no wasted words. The key state 'PAUSED' is front-loaded, and alternatives are listed concisely. Very efficient.

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

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

For a paused tool with one parameter and no output schema, the description fully covers the current state, what the tool does (returns paused response), and what to use instead. No gaps.

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

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

Schema coverage is 100% with one parameter fully described as 'Kalshi or Polymarket market URL'. The description does not add extra meaning beyond the schema, so baseline 3 applies.

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

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

The description clearly states the tool is paused and returns a 'paused' response, with specific verbs like 'returns a paused response'. It distinguishes from siblings by naming live alternatives: licium_scan_edges and licium_discover.

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 agents not to use this tool because it's offline, and provides clear alternatives for similar functionality (weather edge, find verified agents). No ambiguity.

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

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

Annotations already declare readOnlyHint=true, so the description's assertion of browsing and comparing is consistent. It adds behavioral context by listing capabilities (search, compare, health check) and indicating the tool is non-destructive. While it doesn't detail rate limits or data freshness, for a discovery tool this suffices. No contradiction with annotations.

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

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

The description is concise and well-structured: a lead sentence, a bulleted list of capabilities, and a clear 'WHEN TO USE' section. Every sentence adds value, and the formatting aids quick scanning. No 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?

Despite lacking an output schema, the description explains what results include (reputation scores, success rates, pricing) and covers multiple use cases (search, compare, status, alternatives). This provides a complete picture for a browse/compare tool.

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

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

Schema coverage is 100%, so baseline is 3. The description goes beyond the schema by providing natural language examples (e.g., 'email sending MCP servers') that illustrate how to use the query parameter. This adds contextual understanding without repeating schema definitions.

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 specific examples like searching for tools/agents, checking status, and finding alternatives. It also differentiates from siblings by noting 'If you just want results, use licium instead.' This makes the purpose highly specific and distinct.

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

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

The description explicitly says 'WHEN TO USE: When you want to browse, compare, or check before executing. If you just want results, use licium instead.' This directly tells when to use this tool versus the sibling 'licium'. It also mentions integration with licium_rent for follow-up actions.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with registration and reporting. The description adds critical transparency: 'Legacy chain-template sharing is parked' (no function). However, it doesn't disclose whether registration overwrites existing agents or whether report updates records, leaving some behavioral gaps.

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

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

The description is highly concise: three action lines plus a lead sentence. It front-loads the purpose and uses bullet-style formatting for actions, making it scannable. Every sentence serves a purpose.

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

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

Given the tool's complexity (17 parameters, 3 actions, many siblings), the description covers the basic actions but lacks details on behavior (e.g., what happens on duplicate registration, response format). No output schema exists, so description should provide more context. It meets minimum viability but has gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by organizing parameters by action (e.g., 'register: provide name (REQUIRED), description, capabilities...'), clarifying which are required per action. This structuring helps an agent navigate 17 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 states the tool's purpose: 'Manage your presence on Licium. Register agents and report tool quality.' It specifically identifies the three actions (register, report, share) and distinguishes this management tool from the listed sibling tools (e.g., licium_discover, licium_scan_edges), which handle different tasks.

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

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

The description lists the actions but does not explicitly guide when to use this tool versus its siblings. For instance, it doesn't say 'use licium_manage for registration, use licium_discover for finding agents.' The context from sibling names suggests differentiation, but no direct 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?

Annotations already declare readOnly, idempotent, non-destructive. The description adds that receipts are 'settled' and 'evidence of calibration, not betting advice', which provides minimal extra 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?

Two sentences, highly front-loaded with purpose and content. No redundant or extraneous information.

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

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

Given low complexity (one parameter, rich annotations, simple purpose), the description adequately covers the tool's behavior and output. It states what receipts contain, compensating for no output schema.

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

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

Single parameter 'limit' is fully documented in schema (max 50, default 10). Description does not add additional semantic meaning beyond schema, meeting baseline for 100% 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 it returns 'recent settled prediction receipts' and lists specific fields (forecast, market price, outcome, counterfactual edge). It distinguishes from siblings by focusing on settled receipts for calibration, not analysis or betting.

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 use for calibration evidence but does not explicitly state when to use over alternatives like licium_analyze_market or licium_scan_edges. No exclusion criteria or when-not-to-use guidance.

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

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

Annotations already provide idempotentHint and destructiveHint, so the bar is lowered. The description adds context about requiring a session token and the scoring process, but does not disclose error handling or failure modes.

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

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

Two concise sentences with front-loaded purpose. No superfluous 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?

For a simple registration tool with no output schema, the description adequately covers purpose, prerequisite, and follow-up. It does not specify return values or error conditions, but that is 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 covers 100% of parameters with descriptions; the description adds the default for sport ('mlb') but little else beyond schema, warranting the baseline score.

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 ('Enter') and resource ('agent into the weekly prediction tournament'), clearly distinguishing it from siblings like 'licium_tournament_leaderboard'. It also outlines the prerequisite (session token) and subsequent actions.

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 states when to use (requires session token from `licium link`) and implicitly that it's for entering a tournament. It does not explicitly mention when not to use or alternatives, but no sibling duplicates this functionality.

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

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

The description discloses behavioral traits beyond annotations: it deducts 1 credit (mutation), returns specific fields like bet_instruction and pick details, and notes legacy fields. It is consistent with annotations (readOnlyHint false, idempotentHint true). 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 concise (4-5 sentences) and front-loaded with the primary purpose. Every sentence adds value, covering what, how, and output details without unnecessary verbosity.

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

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

Despite no output schema, the description fully explains the return structure, including fields, validity timestamps, and legacy notes. It covers all necessary context for an agent to understand the tool's operation and output.

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 meaning beyond the schema descriptions for 'agent' and 'market'; it merely references the schema's own descriptions. No extra value for parameter semantics.

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 ('Rent') and the resource ('a verified prediction agent's upcoming pick for a market'). It distinguishes the tool from siblings by specifying its unique function of renting picks, which is not covered by sibling tools like licium_discover or licium_analyze_market.

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 usage context by stating 'Not a bet; you act on it yourself,' which guides when to use it. However, it does not explicitly mention when not to use it or provide alternatives among siblings, although the distinction is 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, bears full burden. Discloses public vs paid results, do_not_enter markers, ranking restrictions, and API behavior with keys. Very 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?

Somewhat verbose with product links and URLs; could be conciser. But front-loads main purpose and structures key info.

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 4 params, no output schema, no annotations, description covers returns, filtering, unlock process, and domain. Fully sufficient.

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

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

Schema coverage is 100%, so baseline is 3. Description adds meaning beyond schema: default for min_ev, domain restriction, platform enumeration. Adds 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?

Clearly states the tool scans weather prediction markets for expected-value edge using Weather Agent estimates. Distinguishes from sibling tools by focusing on edge scanning.

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 context for usage (scanning edges, filtering by platform and min_ev) and explains how to unlock details via POST endpoints. Lacks explicit exclusion of alternatives but adequate.

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

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

Annotations already indicate read-only, idempotent behavior. The description adds that returned data includes tier, medals, rating for season, individual ranking for weekly, and mentions calibrated probabilities. This enriches understanding beyond the annotations.

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

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

Two sentences, front-loaded with the main function, then conditional behavior, then note on interpretation. No unnecessary words; every sentence is informative.

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

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

Given no output schema, the description adequately hints at output format (season standings vs. weekly ranking with specific fields) and mentions calibrated probabilities. Could mention sport parameter explicitly, but since schema covers it and it's optional with default, it's nearly 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 has 100% description coverage, so baseline 3. The description adds semantic value by explaining how the absence vs. presence of tournament_id changes the result, and that sport defaults to 'mlb'. This provides behavioral context around 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 states the tool returns ranked prediction agents from the weekly tournament. It distinguishes between season standings (without tournament_id) and weekly ranking (with tournament_id), making its purpose unmistakable and differentiating it from sibling tools.

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

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

Explicitly explains when to use without vs. with tournament_id, and notes the default sport. The phrase 'you decide whether and how to act' suggests interpretation. Lacks explicit alternatives or when-not-to-use, but is clear enough for most contexts.

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