Alya Hub

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

No annotations provided. Description does not disclose whether operations are read-only, destructive, or any side effects. No mention of authorization or rate limits.

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

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

Two concise sentences that front-load the purpose with zero 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?

Tool has 2 params, no output schema, no annotations. Description omits behavioral details, output format, and guidance on selecting between list and lookup actions.

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 50%; description fails to add meaning beyond the schema. Does not explain the difference between 'list' and 'lookup' actions or how to use the slug 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?

Clearly states verb (list, look up, discover) and resource (other agents in Alya Hub catalog). Distinct from sibling tools like web_search or image_gen.

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 this to delegate work to specialised agents', providing clear context for when to use the tool. No exclusions or alternatives 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 bears full responsibility for behavioral disclosure. It only states a read operation ('Get') but omits details like rate limits, authentication needs, data freshness, or potential latency.

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 12-word sentence with no redundancy. It front-loads the key information: what the tool does and what it returns.

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 tool with no output schema and no annotations, the description provides minimal context. It identifies the output fields but does not specify format, units, or data source. While adequate for a simple status check, it could be more 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 input schema has 0 parameters, so the baseline is 4. The description adds meaning by enumerating the output fields (equity, cash, open positions, last lessons), which helps the agent understand what data to expect.

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

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

The description uses a specific verb 'Get' and identifies the exact resource: 'current Alpaca paper-trading status', listing key fields (equity, cash, open positions, last lessons). This clearly distinguishes it from sibling tools like agent_registry or web_search.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses the tool searches a curated catalog and lists result fields, implying a read-only operation. While it doesn't mention authorization or rate limits, the behavioral context is adequate for a search 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 unnecessary words. It front-loads the core function and follows with usage guidance, 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?

For a simple search tool with two optional parameters and no output schema, the description is fairly complete. It explains the source, result contents, and use case. Some details like sorting or pagination are missing but not critical.

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 parameters are well-documented in the schema (limit with range, category with examples). The description reinforces the category parameter by listing example categories, but adds little beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool searches a curated catalog of business tools (FindMyAppz) and specifies what each entry contains (slug, name, category, tagline, etc.). It distinguishes from sibling 'web_search' by positioning itself as an alternative for specific business tool discovery.

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 to use it for discovering purpose-built tools as an alternative to generic web search when solving a specific business problem. This provides clear context, though it lacks explicit when-not-to-use instructions.

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

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

With no annotations, the description carries full burden. It mentions delegation to internal tools but lacks details on behavioral traits such as required permissions, rate limits, error handling, or response format. The description is vague about how the tool operates beyond its purpose.

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: two sentences that front-load the tool's name and role, followed by specific use cases. No extraneous information, every sentence contributes to understanding.

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

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

Given a simple agent tool with 2 parameters and no output schema, the description adequately covers core purpose and use cases. However, it lacks guidance on parameter usage (especially lang) and expected response behavior, leaving gaps for an agent to resolve.

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 2 parameters (lang, question) with 0% schema description coverage. The tool description does not mention or explain these parameters, providing no additional meaning beyond the field names and enum values. An agent must infer usage from the names alone, which is insufficient.

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 as a general question-answering agent ('Ask Alya - the operator agent') and specifies use cases: general questions, opinions, multi-step reasoning, and delegation to internal tools. This effectively distinguishes it from sibling tools like web_search or image_gen which are specialized.

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 guidance on when to use ('for general questions, opinions, multi-step reasoning, or to delegate to Alya's internal tools'), but does not explicitly state when not to use or name alternatives. An agent can infer that for specialized tasks, sibling tools are preferred, but this is not made 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?

No annotations are provided, so the description must reveal behavioral traits. It discloses that the summary is AI-generated, based on CelebTrack's continuously-updated dataset, and not a generic web scrape. It also mentions pricing. However, it does not discuss error handling, latency, or authorization requirements, which would enhance 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 front-loaded with the tool's purpose, followed by return types, use cases, and background. While it is somewhat verbose, each sentence adds value. The use of bold for key terms helps readability. Could be slightly more terse, but overall well-structured.

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

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

Given the tool has only one required parameter, no output schema, and no annotations, the description does a good job covering what the summary contains, the data source, pricing, and target users. It provides sufficient context for an AI agent to decide when and how to use this tool effectively.

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

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

The input schema has one parameter (celebrityId) with 100% coverage. The description adds useful context by explaining how to obtain the ID ('use the 'celebrities' list endpoint or chat ask Alya'), which goes beyond the schema description. This extra guidance earns a score above 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 it returns an 'AI-generated intelligence summary on a celebrity' and enumerates specific contents: activity timeline, sentiment shift, controversies, brand-deal signals, and TL;DR. It distinguishes from generic web scrapes, and the verb 'summary' combined with the resource 'celebrity' is specific and 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 explicitly lists use cases: PR agents, brand-safety screening, casting/sponsorship research, social-media strategists. It also clarifies that it's a premium service with a cost ($0.05/summary) and a specific data source (CelebTrack), which helps decide when to use. No explicit when-not, but the context is clear.

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

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

With no annotations, the description must cover behavioral traits. It mentions the output (in-character reply) and hints at mutation via 'send.' However, it lacks details on rate limits, auth requirements, error handling, or cost implications beyond the pricing line. The description is adequate but could be more transparent.

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

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

The description is concise: four sentences that efficiently cover purpose, the clone concept, use cases, and pricing. No redundant information; 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?

The description covers purpose, usage context, parameter discovery, and pricing. Without an output schema, it only states the return type ('in-character reply'), which is minimal but acceptable given the tool's simplicity. It is sufficient for an agent to select and use 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 coverage is 100% (both parameters have descriptions). The description adds value by explaining that cloneId is discoverable via alya_iconic_clones, which is extra guidance beyond the schema. This improves usability.

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 'Send a message to an iconic character clone on Sosie... Returns the clone's in-character reply,' specifying the verb, resource, and output. It also distinguishes the tool from siblings by mentioning that clone IDs come from alya_iconic_clones.

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 explicit use cases (entertainment agents, creative writing assistants, etc.) and notes the premium cost and proprietary nature. It does not explicitly state when not to use it or name direct alternatives, but the context provided 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?

No annotations provided, so description bears full burden. Describes data fetched (demands with attributes) but does not explicitly state that the tool is read-only or has no side effects. Adequate but could be improved.

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

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

Two sentences with no waste. First sentence gives main purpose and key detail (real users, $1+), second adds use cases.

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

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

Given simple parameters and no output schema, description covers what the tool returns, its purpose, and typical use cases. No gaps evident.

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 description adds little beyond schema. Mentions limit and category but no additional meaning or constraints. 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 aggregates top consumer demands from AskFor, with specific details about real users paying $1+. It distinguishes from siblings by being the only trending demands tool.

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

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

Provides explicit use cases like surfacing unmet market needs and pre-product validation, implying when to use. Lacks explicit when-not or alternatives, but the context is clear.

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

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

No annotations; description fully discloses returns (severity, description, recommendation), source (Symptia engine), and limitation (not medical advice). Good transparency for a safety-critical 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 sentences plus a disclaimer, each sentence serves a purpose. Front-loaded with core function, 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?

No output schema, but description adequately describes output fields. Lacks format details, but sufficient for single-parameter 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 100% with clear description of 'drugs' parameter. Description adds '2-10' and 'pairwise' but does not significantly enhance schema meaning beyond reiteration.

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?

Starts with specific verb 'Check' and resource 'pairwise drug-drug interactions', clearly defining scope (2-10 medications). Unambiguous and unique 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?

Provides explicit use cases ('medication safety reviews, polypharmacy checks, or pre-prescription screening') and a disclaimer about not substituting medical advice. No exclusions needed given specificity.

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 fully discloses behavioral traits: it is a paid call ($0.10), invokes Grok AI with full gem context, uses Father's curated database, and returns a detailed appraisal. This is comprehensive and transparent.

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

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

The description is concise and front-loaded, starting with the core action and output, followed by use cases and cost. Each sentence serves a purpose 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?

Despite the lack of an output schema, the description enumerates all return fields explicitly. It also covers the cost, AI usage, and the single input parameter. The tool's complexity is low, and the description is fully sufficient for an agent to understand invocation and behavior.

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 required parameter 'gemId', describing it as a 'GemHunt gem id (UUID or numeric)'. The description adds context about the platform but does not provide additional semantic depth beyond the schema's own description, warranting a baseline score 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 it triggers a Grok-AI gemological appraisal for a single gem on GemHunt. It specifies the exact outputs (estimated retail value, confidence interval, etc.), making the tool's purpose highly specific and distinct from the listed siblings, which are unrelated.

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 lists use cases: 'collectibles agents, jewelry e-commerce, insurance estimation, or pre-purchase due diligence.' It also notes the premium cost ($0.10/call) and the fact that it calls Grok with full gem context, providing clear guidance on when 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?

No annotations exist, so the description must disclose behavioral traits. It reveals the data source (GemHunt scraping) and return fields but does not state that the tool is read-only, discuss rate limits, or describe side effects, leaving gaps in transparency.

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

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

The description is concise (three sentences) with a clear front-loaded purpose, followed by engine details, use case, and filter instruction. No extraneous content.

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, the description adequately covers the purpose, return content (gem fields), and filter usage. It misses pagination details but limit parameter is documented.

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

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

Schema coverage is 100% with both parameters documented. The description adds minimal value beyond schema by restating minScore's role in 'strong_gem' status, but does not enhance understanding of the limit 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 discovers undervalued antiques, collectibles, and rare items, with specific criteria and data sources. It distinguishes itself from sibling tools like alya_seismic_recent by focusing on gem/arbitrage opportunities.

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

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

The description says 'Use to find arbitrage opportunities or rare finds,' providing a clear context for use. However, it does not mention when not to use this tool or compare it to alternatives like other discovery tools on the server.

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

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

With no annotations, the description carries full burden. It implies a safe read operation but does not explicitly state it is read-only or non-destructive. It also does not mention ordering or pagination beyond the limit parameter.

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, front-loaded with the main purpose, followed by return fields and use cases. Every sentence adds value 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?

For a simple catalog tool, the description covers purpose, parameters, and return fields adequately. It could mention if authentication is needed or ordering, but overall it is complete enough for the low 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 the description adds minimal extra meaning about parameters. It provides context like example categories but does not improve on what the schema already provides, meeting 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 clearly states the tool browses a catalog of iconic figures, listing specific examples (Carl Sagan, Napoleon, Nietzsche) and the fields returned. This differentiates it from sibling tools like web_search or polymorph markets.

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

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

The description explains use cases (research, debate prep, education, chat) and implicitly tells when to use it. It does not explicitly contrast with siblings, but the sibling tools are sufficiently different that confusion is unlikely.

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 the tool's functionality, calibration, network effect, and cost. No annotations are provided, but the description adequately explains the behavior without 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, front-loaded with the purpose, and each sentence serves a purpose, including usage guidance, output details, and a tagline.

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 values and usage context, making it complete for agent decision-making.

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

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

The schema has 100% coverage with descriptions, and the description adds context by explaining the actionDescription format, output details, and optional domain hint, providing additional 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 defines the tool as a 'Pre-flight risk check against Alya's loss memory' and details the inputs and outputs, distinguishing it from sibling tools by focusing on financial risk assessment.

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

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

Explicitly states when to use: 'BEFORE placing any non-trivial bet, trade, gig pitch, or financial decision' and gives examples, but does not explicitly mention when not to use or alternatives.

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

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

With no annotations, the description effectively communicates the tool's behavior: it returns probabilistic forecasts with a specific time horizon, model, and spatial resolution. It discloses model version and feature count, and does not contradict any 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, front-loaded with the core function, and contains no redundant information. Every sentence adds value.

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

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

Given the lack of output schema, the description adequately explains the return format (1° grid, probabilities for three magnitudes). The parameters are well-covered in the schema. The description could optionally mention spatial coverage or update frequency, but it is sufficient for the task.

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 both parameters (limit and minProb55) with clear descriptions. The tool description does not add extra meaning beyond the schema but does contextualize the output (probabilities for three magnitude thresholds). The minProb55 parameter only mentions M5.5+, while the description lists M6.0+ and M7.0+ as well, which may cause slight ambiguity.

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 produces 72-hour earthquake probability forecasts using a specific model (LightGBM+XGBoost v23.0 with 230 features) and specifies output format (1° grid cells, probabilities for M5.5+, M6.0+, M7.0+). This distinguishes it from sibling tools like alya_seismic_recent (recent earthquakes) and others.

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 suggests use cases: 'risk assessment, insurance pricing, or to surface high-risk regions before events happen.' It does not state when not to use or mention alternatives, but the context of sibling tools implies distinction from recent earthquake data.

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

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

No annotations provided, so description must convey behavior. It implies a read-only query returning earthquake data. It does not detail any side effects, rate limits, or prerequisites, but the straightforward nature of the tool makes this 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?

Two sentences, no wasted words, front-loaded with key information. Highly efficient.

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

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

Given 3 parameters with full schema descriptions and no output schema, the description covers purpose, use cases, and returned fields. It could mention return format (list) or more on magnitude range, but overall it's 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?

Schema description coverage is 100% (hours, limit, minMagnitude all have descriptions). The tool description does not add further parameter semantics beyond what the schema already provides, so 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 retrieves recent earthquakes worldwide from specific aggregators (USGS+EMSC+GFZ) and lists returned fields (magnitude, location, depth, time, source). It distinguishes from sibling 'alya_seismic_forecast' by focusing on recent events.

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 use cases: real-time monitoring, news, risk assessment, verification of felt events. Does not explicitly mention when not to use or alternative tools, but the sibling name implies forecast usage is separate.

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, but the description discloses the tool's Bayesian inference, outputs (ranked conditions, probabilities, red flags), cost ($0.10/call), and the serious nature of healthcare errors. It does not detail session state or latency, but is transparent enough for a single-param 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 informative but longer than necessary, including a URL and pricing detail that could be omitted. It is front-loaded with purpose but could be more concise while retaining 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?

For a tool with no output schema and no annotations, the description fully covers input, outputs, use cases, limitations, and cost. It provides sufficient context for correct invocation 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%. The description adds value with an example input and notes language flexibility, exceeding the schema's own description. This helps the agent provide appropriate input.

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 starts a Bayesian symptom-to-diagnosis session via Symptia, returns ranked conditions, probabilities, follow-up questions, and red flags. It uses specific verbs and resources, distinguishing it from siblings like alya_drug_interactions.

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 specifies use cases (triage assistants, telehealth pre-screening, etc.) and explicitly states it is not a substitute for licensed clinical diagnosis. It does not directly contrast with sibling tools but provides clear context.

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

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

No annotations provided, so description carries burden. Mentions data source (Velene's miroir engine) but does not disclose limitations like update frequency or accuracy.

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 efficient sentences that front-load key information 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?

No output schema but description lists output fields (temp, humidity, UV, condition, icon). Adequate for a simple retrieval tool.

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

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

Single parameter 'city' with example values in description. Schema coverage is 100%, and description adds clarifying examples 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?

Clearly states it retrieves current weather for any city and lists specific output fields. Distinguishes from siblings as the only weather-focused tool.

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

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

Provides explicit use cases like travel planning and agricultural decisions. Lacks exclusions or alternatives, but no similar tools exist so guidance is 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?

No annotations are present, so the description carries the transparency burden. It discloses cost, input requirements, and return order. However, it does not clarify whether the tool is read-only or has side effects, nor any permissions or rate limits.

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

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

Two sentences with no extraneous text. The most critical information (capacity, cost, required fields) is front-loaded. 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?

Given no output schema, the description adequately explains the return format. It covers purpose, limits, cost, and field documentation. Minor gaps: no explanation of what calibration does or result structure, but sibling tools may fill this.

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

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

The schema has 0% description coverage, but the description adds meaning: it explains each item must include 'prediction' and optionally 'confidence', 'domain', 'stakes'. It also states the return is an array matching input order, going beyond the raw 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 verb 'calibrate' and the resource 'predictions', specifying it is a batch version limited to 25 items. It distinguishes from sibling tools like 'calibrate_decision' by highlighting the batching capability and flat cost.

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 tells when to use it ('in a single MCP call') and includes cost details, but does not explicitly contrast with the single calibration sibling. It implies batching is beneficial but lacks 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?

Discloses persistence of prediction and return of call_id, along with outputs (calibrated confidence, similar cases, confidence interval, Kelly stake, counter-argument). No annotations exist, so description carries the behavioral burden well.

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

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

Two sentences, front-loaded with purpose, followed by details. No redundancies.

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?

Describes key outputs and feedback mechanism, but lacks details on domain filtering logic or error handling. Still strong given no output schema and moderate 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. Description adds meaning: 'domain' filters similar cases, 'stakes' used for kelly_stake, 'confidence' is initial, 'prediction' should be one sentence. This goes 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 uses a specific verb ('calibrate') and resource ('a prediction's confidence against historical outcomes'), clearly distinguishing it from sibling tools like batch_calibrate by implying individual prediction focus.

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?

Describes what it does and the feedback loop via POST /api/calibrator/feedback, but does not explicitly state when not to use it or mention alternatives for batch processing.

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 fully carries the burden. It implies a read operation ('look up') but does not explicitly confirm it is non-destructive or safe. It lacks details on side effects, rate limits, or authentication requirements. However, the behavior is straightforward and the return structure is described.

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 composed of two short, direct sentences. The first states the purpose and the second lists return fields. There is no redundancy or extra content. It is well front-loaded and 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?

Given the tool has one parameter, no output schema, and no annotations, the description covers the essential aspects: what it does and what it returns. It could mention error handling for nonexistent domains, but for a simple lookup, it 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?

Schema coverage is 100% with one required parameter. The description adds value by providing an example of a domain prefix ('freelance', 'prediction-market', 'equities'), clarifying the expected format beyond the schema's generic description. This improves understanding.

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

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

The description clearly states the tool's purpose: looking up historical win-rate for a prediction domain. It specifies the verb 'look up', the resource 'prediction domain in Alya's outcome ledger', and lists the return fields. Among sibling tools, this is distinct and 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?

No guidance is provided on when to use this tool versus alternatives like alya_seismic_forecast or alya_loss_check. There are no context clues, exclusions, or criteria for selection. The description is purely declarative without decision support.

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

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

With no annotations, description carries full burden. Only states 'Returns a URL' but omits behavioral traits like processing time, cost, content filters, or error 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?

Single sentence efficiently conveys core purpose and output. Could be slightly more structured but wastes no 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?

Lacks output schema and has minimal schema descriptions. Does not clarify response format, error cases, or any constraints beyond dimensions.

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 33% (only prompt has a description). Description adds no extra meaning beyond repeating default dimensions; width/height parameters remain undocumented.

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 action (generate), resource (image), dimensions (1024x1024), model (FLUX.1-schnell), and output (URL). Completely distinguishes from unrelated 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 on when to use this tool versus alternatives. Mentions the model but no conditions, 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 full burden. It reveals the tool returns categories and a block decision based on '$548 loss-forensics', offering some transparency. However, it does not explain error handling, edge cases, or how the block decision is determined in 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 extremely concise with two sentences. The first sentence lists categories, the second gives usage context. No redundant or missing information; every word serves a purpose.

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

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

For a simple tool with one parameter and no output schema, the description is fairly complete: it specifies input, output (categories and block decision), and usage. It could be improved by briefly describing the output format (e.g., list of objects with title, category, block status).

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?

Despite 100% schema description coverage, the description adds meaningful context by listing the possible categories and explaining the tool's purpose. This goes beyond the schema's basic specification of an array of strings.

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 classifies Polymarket market titles into specific categories and indicates whether Alya would block the market. This distinguishes it from sibling tools like polymarket_edge or polymarket_signals.

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

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

Description explicitly advises using the tool to pre-screen markets before placing real money, providing clear context. However, it does not mention when not to use it or suggest alternative 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 fully disclose behavior but only states the purpose. It does not mention read-only nature, authentication needs, rate limits, or return format.

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?

One sentence with no filler. Front-loaded with the action ('Get') and resource ('edge ranking'). Efficient and to the point.

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

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

Given no output schema, the description should explain return values but does not. It also lacks context about what 'edge' means beyond disagreement. Incomplete for a tool with a single optional parameter.

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 description does not mention the 'limit' parameter at all. Schema description coverage is 0%, so the agent gets no guidance on parameter meaning or 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?

The description clearly states 'Get Alya's current edge ranking on Polymarket: top markets where Alya's model disagrees with current price.' It specifies the verb (Get) and resource (edge ranking), and distinguishes from siblings like alya_ask and web_search.

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

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

No guidance on when to use this tool versus alternatives like alya_ask or web_search. Lacks explicit context 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?

No annotations provided, so the description carries full burden. It describes the data source and filtering logic but does not explicitly state that the tool is read-only, lacks rate limits, or other behavioral traits. However, it does disclose the exclusion of blocked categories and the 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, front-loaded with the tool's purpose, and efficiently covers the source, filtering, and output format without 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?

Despite no output schema, the description enumerates each field in a row (trader, market title, side, price, size, category, suggested edge), fully informing the agent of the return structure. All three parameters are explained, making the tool complete for its intended use.

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

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

Schema coverage is 100%, baseline 3. The description adds context for each parameter: 'hours' as lookback, 'limit' as max rows, and 'includeBlocked' to include blocked categories with a tag. It names blocked categories as 'proven losers', adding meaning beyond the schema.

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

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

The description clearly states it returns live copy-trading BUY signals from a specific watchlist, filtered by a quality engine, with blocked categories excluded. It distinguishes itself from siblings like polymarket_top_traders or polymarket_edge by specifying the signal filtering and output fields.

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 implicitly tells when to use the tool (to get filtered signals from top traders). It does not explicitly mention alternatives or when not to use, but the context is clear enough for an AI agent to infer appropriate 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 provided, the description carries the full burden. It discloses the refresh interval (every 4h), the union logic (top-20 all-time + top-5 last-24h), and the data fields returned. While it doesn't discuss rate limits or authorization, the tool is read-only and non-destructive; the description is sufficient for safe invocation.

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

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

Two sentences with zero wasted words. First sentence defines the tool's output, refresh, and columns; second sentence states its use case. Highly efficient and easy to parse.

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

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

For a simple list tool with two parameters and no output schema, the description adequately covers the union logic, refresh timing, output fields, and intended use. No significant gaps remain for typical usage.

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

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

The input schema already documents limit and window parameters with defaults and constraints. The description adds value by explaining the output structure (wallet, window, rank, lifetime profit) and the refresh behavior, which is not present in the schema. With no output schema, this extra context is valuable for interpretation.

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 explicitly states it returns a curated leaderboard of Polymarket top traders, using a union of top-20 all-time and top-5 last-24h profit, refreshed every 4h. It specifies output columns (wallet, window, rank, lifetime USD profit) and its intent for copy-trading watchlists. This clearly distinguishes it from sibling tools like polymarket_signals or polymarket_categorize.

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: 'Use to construct your own copy-trading watchlist.' It does not explicitly mention when not to use it or compare to alternatives, but the stated use case is specific and helpful. Minor deduction for lacking exclusion 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 provided, so description carries burden. Mentions it is a search and returns results, but lacks details on read vs write, rate limits, or behavior on errors.

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

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

Single sentence, no fluff, efficiently conveys core purpose and language scope.

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

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

Given no output schema, description mentions synthesized answer with sources, which is helpful. Could specify result format or citation style, but adequate for a search tool.

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

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

Schema coverage is 100% with descriptions for both 'query' and 'lang'. Description adds 'in Turkish or English' which aligns with enum, but no extra semantics 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?

Description clearly states verb 'Search', resource 'live web', and output 'synthesized answer with sources'. However, no explicit differentiation from sibling 'alya_ask', which might also involve answering queries.

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 by 'Search the live web', but no explicit guidance on when to use this tool vs siblings or alternatives like 'alya_ask'.

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 output fields and quota limits, but fails to explain behavioral traits such as authentication needs, whether data is persisted, or how 'locked niche keywords' are configured. This leaves gaps in understanding the tool's side effects and prerequisites.

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 plus quota info. It front-loads the purpose and immediately adds value with no wasted words. Every sentence earns its place.

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

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

The tool has 2 parameters and no output schema, so the description must compensate. While it explains what is returned and quota limits, it omits critical context about prerequisites (e.g., how 'locked niche keywords' are set) and potential errors. This incomplete picture leaves some uncertainty for the agent.

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

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

Schema description coverage is 100%; both parameters (count, locale) are adequately described. The description adds context by mentioning 'next N best' (tying to count) and 'locked niche keywords' (not a parameter). This adds marginal value beyond the schema, meeting the baseline of 3.

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

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

The description clearly states what the tool does: 'Find the next N best video topic opportunities for your channel.' It specifies the verb (find), resource (video topic opportunities), and scoping (for your channel). It also lists returned fields, distinguishing it from siblings like youtube_get_recommendations.

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 generating topic ideas based on 'locked niche keywords and brand voice,' but does not explicitly state when to use this tool versus alternatives like youtube_get_recommendations or youtube_generate_video. No exclusions or prerequisites 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 exist, so description carries the burden. It discloses that free tier does not upload and that Pro/Studio drafts can be uploaded. Does not mention rate limits, authentication, or side effects, but given the tool's non-destructive nature, 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?

Two sentences with clear structure: first states what the tool does, second explains tier behavior. 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?

Despite no output schema, the description enumerates what the draft contains. Covers the key aspects for a generation tool, though could mention that topic is required and how to format 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 coverage is 67%; topic and durationSec have descriptions but titleHint lacks one. The description does not add any additional meaning beyond the schema (e.g., format constraints for topic). Does not compensate for the missing titleHint 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 clearly states the tool generates a full draft video with specific components (title variants, description, tags, script, thumbnail prompt, estimated duration) for a given topic. It is distinct from sibling tools like youtube_upload_video.

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?

Describes tier differences (free vs Pro/Studio) and mentions eligibility for youtube_upload_video, guiding when to use each. Does not explicitly exclude other use cases but provides sufficient 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 carries full burden. It only discloses the time range and return fields, but omits safety profile (read-only vs destructive), authentication requirements, and rate limits. For a summary tool, read-only assumption is reasonable but not stated.

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

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

Two sentences with no redundancies. First sentence captures purpose and parameter, second lists return data. Every part is necessary.

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 tool with no output schema, the description covers purpose, parameter constraints, and return fields. Missing details like authentication or whether the operation is safe, but the context is largely 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?

The description adds critical details beyond the schema: default value (30), maximum (90), and semantic meaning ('last N days'). Since schema description coverage is 0%, this compensates effectively.

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

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

The description clearly states the verb 'Get' and the resource 'tenant-scoped performance summary', and distinguishes it from sibling tools like youtube_get_recommendations by specifying the return fields (videosPublished, videosSandbox, etc.).

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

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

No explicit guidance on when to use this tool vs alternatives like youtube_find_opportunities or youtube_get_recommendations. The description does not mention prerequisites 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?

The 'Get' verb implies a read-only operation with no side effects, but without annotations, the description could explicitly confirm non-destructiveness and mention any quota implications or 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?

Single sentence, front-loaded with the core purpose, then a comma-separated list of outputs. Every word serves a purpose, 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?

For a parameterless, read-only tool, the description covers the essential purpose and return fields. It could briefly explain terms like 'abort criteria' for clarity, but is largely 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?

No parameters exist, so the description need not explain them. It adds value by listing the output attributes (mode, week, etc.), which helps the agent understand what information will be returned.

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 'Get the current state of Alya's adaptive YouTube engine' and lists specific attributes (mode, week, velocity, counters, etc.), distinguishing it from sibling tools like youtube_get_performance or youtube_health_check.

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

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

No explicit guidance on when to use this tool versus alternatives like youtube_health_check or youtube_get_performance, though the name and description imply it's for pipeline status monitoring.

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

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

No annotations provided, so description carries full burden. It lists return types (onboarding gaps, missed velocity, etc.) but lacks info on side effects, permissions, or mutability.

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

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

Two concise sentences with no wasted words, front-loaded with purpose.

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

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

Given simple no-param tool, description adequately explains return types. Missing usage scenarios but 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?

Input schema has no parameters, so description adds value by detailing what the tool returns. Baseline high due to no params.

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

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

Description clearly states 'Get prioritized, channel-specific recommendations' which specifies verb, resource, and scope. Distinguishes from siblings like youtube_find_opportunities and youtube_get_performance.

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

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

No guidance on when to use this tool over alternatives, no exclusions or context 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, so description fully carries burden. Declares it is free and no-quota, which is crucial behavioral info. Describes exactly what it returns, with no hidden effects.

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

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

Two sentences only, both front-loaded with essential info. No wasted words; every part earns its place.

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

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

Given simplicity (0 params, no output schema), description covers purpose and return values adequately. Could mention error states or latency implications, but not critical for a health probe.

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?

Zero parameters with 100% schema coverage; description adds value by listing the return fields (tier, usage, caps, etc.), which the input schema does not provide.

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 tier, usage, caps, connection status, and niche config. Verb 'returns' and resource 'health probe' are precise. Distinct from sibling youtube tools that generate or upload content.

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 advises use on every cold start, providing clear context. Does not state when not to use or mention alternatives, but the advice is actionable and sufficient for the tool's role.

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

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

No annotations provided, so description carries full burden. It discloses write operation (upload), tier-dependent behavior, and authentication needs but does not detail return values, error handling, or async behavior. Adds value 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?

Two concise sentences, front-loaded with main action. Efficiently communicates core functionality and tier differences. Could use minor structuring (e.g., separating tiers) but overall well-sized.

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

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

Covers main behavior and tier differences. Lacks details on return format (no output schema), publish parameter meaning, and error states. For a tool with 2 params and no output schema, more context is needed for complete 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 0% and description does not explain the two parameters (publish, tenantVideoId). For low coverage, description must compensate, but it fails to add meaning beyond the schema. Baseline should be higher but lacks any parameter info.

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 uploads a generated draft to YouTube, distinguishing between free tier (sandbox preview) and Pro/Studio (actual upload with OAuth). This differentiates it from siblings like youtube_generate_video (draft creation) and youtube_get_performance (analytics).

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 describes when to use based on tier and OAuth requirement. It does not directly compare to alternatives or specify when not to use, but the context implies it follows draft generation. Could be more explicit about prerequisites.

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