Hemrock MCP

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds value by disclosing the authentication requirement (Hemrock API key) and the fallback behavior (returning a checkout URL without it). It also describes the return content (per-round snapshots and final ownership/dilution state), beyond what annotations provide.

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) and front-loaded with the core action. Each sentence contributes distinct information: computation, output, and authentication/pointer. There is no filler or redundant 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 single-parameter tool with no output schema, the description adequately explains what it returns (per-round snapshots and final state) and covers critical context (API key requirement and checkout URL fallback). It does not detail the output format, but that is acceptable given the tool's moderate complexity and the provided annotations.

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

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

The input schema covers the single 'events' parameter with a detailed description including types and an example, so the baseline is 3. The description adds value by pointing to list_concepts/get_concept for the event structure, providing extra guidance beyond the schema. It also lists the event types, though redundant with 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 uses the specific verb 'Computes' and clearly identifies the resource ('a cap table'), enumerating the event types it handles (founders, priced rounds, SAFEs/notes, option pools, warrants). While it precisely defines the tool's scope, it does not explicitly distinguish it from sibling compute tools like exit_waterfall_compute or fund_economics_compute.

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 contextual guidance by mentioning the required product ('Cap Table & Exit Waterfall product') and pointing to list_concepts/get_concept for the event structure. However, it does not explicitly state when to use this tool versus alternatives, nor does it exclude any specific scenarios.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the read-only nature is covered. The description adds the product requirement (API key), which is useful behavioral context not in the annotations. It also states the operation distributes an exit valuation across the cap stack, providing insight into the computation.

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 core purpose, followed by access requirement and input hints. Every sentence earns its place with no redundancy.

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

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

The description covers purpose, access, and input reference, and annotations handle safety. However, with no output schema, it does not explain what the tool returns (e.g., a distribution schedule or a waterfall report). This is a noticeable gap for a compute tool with a nested model input.

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

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

Schema coverage is 100%, so the schema documents both parameters. The description adds value by instructing to pass a 'model' object and numeric 'exitValuation', and also directs users to list_concepts for the model structure, which is not in the schema. This supplementary reference improves semantic clarity.

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 'Computes an exit waterfall' with a specific resource (cap stack) and scope (preferences, participation, conversions, options, warrants). It distinguishes from siblings like cap_table_compute and fund_economics_compute by focusing on exit valuation distribution.

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 indicates when to use the tool (when computing an exit waterfall) and explicitly states the prerequisite: 'Requires a Hemrock API key with the Cap Table & Exit Waterfall product.' It implies this is the right tool for exit waterfall calculations, though it doesn't explicitly mention alternatives 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?

Annotations already declare readOnlyHint and openWorldHint, so the description is not burdened with safety traits. It adds useful context by specifying the outputs (capital calls, fees, NAV, returns) and that any valid API key works, which is an access/auth detail 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?

The description is two sentences, front-loaded with the main action, and contains no redundant or tangential information. Every sentence earns its place.

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

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

For a compute tool with no output schema, the description lists both inputs and outputs, which covers the essential information. It also points to list_concepts and the Fund Economics template for field details, making it complete enough for an agent to proceed.

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

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

The input schema has 100% description coverage for the only parameter, so the baseline is 3. The description adds marginal value by naming 'deployment' (not explicitly in the schema) and instructing to 'Pass an inputs object', but largely mirrors the schema description.

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

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

The description uses the specific verb 'Computes' with the resource 'venture fund economics' and enumerates both inputs (committed capital, fees, deployment, carry tiers) and outputs (capital calls, fees, NAV, gross/net returns). This clearly distinguishes it from sibling tools like cap_table_compute and exit_waterfall_compute.

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

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

The usage context is implied by the input/output list, but no explicit guidance is given on when to choose this tool over alternatives. The 'Free' statement is an access note, not a usage scenario. There are no exclusions or alternative recommendations.

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 agent knows this is a safe read operation. The description adds what information is returned (free status, price, checkout URL) but does not disclose additional behavioral traits such as side effects, external data dependencies, or limitations. Since the annotations cover the safety profile, a mid-score is appropriate.

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

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

The description is only two sentences, with the first sentence front-loading the core purpose and the second providing usage guidance. Every word contributes information; there is no repetition of schema details or filler.

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

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

Given the tool's simplicity (one enum parameter, no output schema, clear annotations), the description fully covers the purpose, the exact return contents, and when it should be used. Nothing essential is missing, and the openWorldHint is consistent with price information being dynamic.

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

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

The single parameter 'model' has an enum and its own schema description, and the schema description coverage is 100%. The tool description does not add any additional meaning beyond the schema; it simply refers to 'model engine' without detailing the specific enum values. Per the baseline for high schema coverage, this is a 3.

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

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

The description clearly states the specific verb (returns) and resource (how to get access to a model engine), listing the exact outputs: free status, price, and checkout URL. This distinguishes it from sibling tools like compute tools (which run models) and other get_* tools (which retrieve different information).

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 a compute tool returns a payment-required error, or to check access before running. It does not mention when not to use or name an alternative tool, but the context is clear and actionable, so this is stronger than merely implied 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?

Annotations already declare readOnlyHint=true, establishing that this is a safe read operation. The description adds that it returns domain-specific best practices and is meant for background context, which is useful. It does not go into deeper behavioral details like pagination or response structure, but given the annotation coverage, the additional context is sufficient to earn a midpoint score.

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

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

The description is two sentences, front-loaded with the tool's action, and each sentence adds value: the first defines the output, the second states its intended use. There is no redundancy 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?

For a simple read-only tool with one optional parameter, the description and schema together provide enough context for correct invocation. The lack of an output schema is mitigated by the clear statement of what is returned. A slight deduction for not describing the response format, but this is not a significant gap for such a lightweight tool.

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

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

The schema provides 100% coverage with an optional topic parameter, an enum, and a clear description. The tool description says 'for a given topic' but does not add further syntax or behavior details beyond what the schema already offers. Thus, the description neither compensates nor detracts, 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 the verb 'Returns' and specifies the resource as 'Hemrock's financial modeling best practices and design principles', with the scope 'for a given topic'. This clearly distinguishes it from sibling tools like get_concept or get_checks, which target different content types.

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

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

The phrase 'Useful as background context for AI interactions' gives clear context for when to invoke. However, it doesn't explicitly state when not to use it or name alternative tools, so it stops short of full exclusionary guidance. Still, it's clear enough for typical use.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds context about the content's purpose but does not disclose additional behavioral traits such as output format or pagination, meaning it only moderately adds value beyond annotations.

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

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

Two sentences, front-loaded with the primary function, followed by a concise use case. Every word adds value, with no redundancy or filler.

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

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

For a simple read-only retrieval tool with one fully described parameter and clear usage guidance, the description is complete. No output schema exists, but the description explains what is returned ('prompts') and their purpose, so the agent has enough context to select and invoke correctly.

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

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

Schema description coverage is 100%, with template_name fully documented including the enum and the special 'all' case. The description adds no extra parameter-level information, so it meets the baseline but does not exceed what the schema already provides.

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

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

Description uses specific verb 'Returns' and resource 'Layer 3 sanity-check and validation prompts', immediately stating the tool's function. It also clarifies the intended use ('audit AI-generated work or catch common modeling errors'), which differentiates it from siblings like get_prompts or get_best_practices.

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

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

The description explicitly states when to use the tool ('Use these to audit AI-generated work or catch common modeling errors'). It does not list alternative tools or exclusions, but the use case is clear enough to guide selection.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value beyond annotations by specifying that the tool returns the full text of a single doc, which implies potentially long output. It also clarifies that the slug must be from list_concepts. No contradictory statements.

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

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

The description is two sentences, front-loaded with the core action, and includes usage guidance without waste. Every sentence earns its place.

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

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

For a simple single-parameter read tool with no output schema, the description is complete: it states what is returned (full text), how to get the input (slug from list_concepts), and when to use it. The annotations cover safety, and the schema covers the parameter. No gaps identified.

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

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

Schema description coverage is 100%, with the slug parameter already described as 'from list_concepts (e.g. "waterfall", "anti-dilution")'. The description repeats 'Get valid slugs from list_concepts' but adds no new semantic information beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns the full text of a single Hemrock modeling concept doc by slug, identifying the specific verb, resource, and scope. It distinguishes itself from siblings like list_concepts by focusing on a single concept and from compute tools by being a read-only retrieval operation.

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

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

The description provides clear usage context: 'Use this to learn how a financial-modeling calculation actually works before building or auditing it.' It also directs users to get valid slugs from list_concepts. However, it does not explicitly mention when not to use this tool or name alternatives other than list_concepts.

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 openWorldHint=false, so the agent knows this is a safe read. The description adds the behavioral nuance that this is a primer to run first, but does not disclose details like output formatting or side effects. Since the annotation covers the safety profile, the description adds minimal but non-essential context beyond that.

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 immediately followed by the key usage instruction. Every sentence earns its place without redundancy or filler.

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

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

For a single-optional-parameter, read-only tool with no output schema, the description covers the main behavior, the optional parameter, and the recommended usage order. It does not elaborate on the content of the primer, but given the simplicity and the rich sibling set, the guidance is sufficient for an agent to invoke it 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% with template_name fully described in the input schema, so the baseline is 3. The description's phrase 'optional template-specific addendum' aligns with the schema's 'template-specific primer' but adds little new meaning; the schema already provides complete 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 uses a specific verb ('Returns') and clearly identifies the resource ('universal context-setting primer for Hemrock models'), distinguishing it from sibling compute and getter tools. It also conveys the scope (plus optional addendum) and positions it as a precede-all tool, eliminating ambiguity about its role.

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

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

The instruction 'Always run this first before any other prompts' explicitly states when to use the tool, establishing it as a mandatory precursor. It does not explicitly mention alternatives or exclusions, but the directive is clear enough for an agent to know this is the initial step. The optional template_name guidance is implied by 'optional template-specific addendum'.

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 annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only nature is covered. The description adds that prompts are 'task-specific' and 'ready-to-use,' which is mildly informative, but it does not disclose any additional behavioral traits such as error conditions, edge cases, or output format. It is consistent with the annotations, so no contradiction.

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

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

The description is two sentences long, front-loaded with the core action and resource, and contains no filler or redundant phrases. Every word contributes to understanding the tool's purpose.

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

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

For a simple read-only tool with two parameters and no output schema, the description provides sufficient context: it states what is returned and for what inputs. It does not need to elaborate on return values because the purpose is clear, though a bit more detail about 'Layer 2' would enrich the context slightly.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no new meaning beyond restating that the tool works with a 'template and task type,' which directly maps to the two parameters. The baseline of 3 is appropriate because the schema already carries the semantic load.

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

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

The description uses a specific verb ('Returns') and identifies the resource ('task-specific Layer 2 prompts') alongside the input scope ('for a given template and task type'). This clearly distinguishes it from sibling tools like cap_table_compute or get_checks, which have different purposes.

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

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

The description implies when to use the tool ('ready-to-use prompts for common modeling tasks') and mentions the required context ('given a template and task type'), but it does not explicitly state when not to use it or name any alternative tools. It lacks the exclusionary guidance that would make it a 4.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds useful context about the return format (compact index of slugs, titles, and descriptions) and the optional filters, going beyond what annotations provide without contradicting them.

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 well-organized sentences that cover the tool's purpose, return format, filtering options, and a pointer to the sibling tool, with no wasted words. It is front-loaded and easy to parse.

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

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

Given the simple read-only nature, the schema with full parameter descriptions, and the read-only annotation, the description adequately covers what the tool does, what it returns, and how to use it further. It doesn't mention ordering or pagination, but these are not critical for a compact index tool.

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

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

The input schema has 100% coverage with descriptions for both parameters and an enum for template_name, so the schema carries the parameter documentation. The description only mentions optional filtering without adding extra semantic detail, warranting the 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 the tool lists Hemrock financial-modeling concept docs, provides specific topic examples, and distinguishes it from the sibling get_concept tool by noting it returns a compact index. The verb 'lists' precisely describes the action and the resource is well-defined.

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 call get_concept to read the full text of any entry, providing a direct alternative and guiding when to use this tool vs its sibling. It also implies usage for obtaining an overview or filtered index, which is 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?

Annotations already declare readOnlyHint and openWorldHint, but the description adds valuable behavioral details: no API key needed, returns pricing information, and includes a checkout URL for paid models. It does not describe output format or pagination, but for a simple listing tool this is adequate.

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

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

The description is two sentences with no redundancy. The first sentence states the core action and output; the second provides usage context and prerequisite. Every word earns its place.

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

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

For a simple read-only list tool with no output schema and no parameters, the description fully covers what the tool does, what it returns, when to use it, and authentication requirements. No critical information is missing.

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

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

The tool has zero parameters and the schema is empty, so the description cannot add parameter-level details. The baseline for 0 params is 4, and the description appropriately focuses on the tool's behavior instead of non-existent 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 uses a specific verb ('Lists') and resource ('Hemrock financial-model engines'), and clearly distinguishes from siblings by specifying these are callable engines with pricing and checkout URLs. It is not a tautology and immediately conveys the tool's unique purpose.

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

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

The description explicitly states 'No API key needed' and instructs to use this 'before authenticating' to discover what you can run and costs. This provides clear when-to-use guidance and contrasts with the authentication-requiring compute siblings.

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