mcp

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

Annotations already mark this as read-only, idempotent, and non-destructive, so the description only needs to add operational context. It adds that the list is 'up to date' and enumerates the returned properties (fees, aprs, supported currencies, active/inactive statuses), giving agents a clear idea of what information to expect. It doesn't discuss rate limits or caching, but for a no-parameter read-only tool this is acceptable.

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

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

The entire description is a single sentence that front-loads the primary action and resource, then lists the relevant data fields. There is no redundant or extraneous wording aside from a minor 'etc.' that signals non-exhaustive fields.

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

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

The description states the provider scope, the kind of data returned, and key fields, which is sufficient for a zero-parameter tool without an output schema. It could be more exhaustive about exact return keys, but the 'etc.' and field list provide adequate completeness for calling the tool.

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

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

The tool has zero parameters and 100% schema coverage, so there is nothing for the description to explain about inputs. Baseline 4 applies because no parameter documentation is needed.

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 'Provides' with a concrete resource ('list of supported blockchain networks by Everstake') and names the included data fields. This clearly distinguishes it from sibling tools, which focus on company profile, contact info, docs, integrations, products, security, solutions, uptime, and staking calculator.

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

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

There is no explicit when-to-use statement or exclusion criteria, but the description's focus on blockchain networks makes the intended context obvious in relation to the non-chain siblings. It does not name alternatives for the same task, so guidance remains implied rather than 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is known to be safe and side-effect-free. The description adds no contradictory behavior and enriches the context by listing the types of data covered, which helps the agent anticipate the response shape. Without additional behavioral quirks (auth, rate limits, pagination), the description does what's needed, so a 4 is justified.

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 fluff. The first sentence lists the content domains in comma-separated format, and the second gives a crisp usage directive. Every word earns its place; the description is front-loaded with the most important information and avoids redundant phrasing.

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

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

For a read-only tool with no parameters and no output schema, the description fully covers what an agent needs to know: what the tool returns and when to call it. It doesn't leave gaps about missing parameters or side effects, and the content list is sufficiently comprehensive to set expectations. Nothing is absent that would prevent correct invocation.

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

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

The input schema has zero parameters, so there is nothing to document. With a baseline of 4 for parameter-less tools, and because the description doesn't need to compensate for any schema gaps, this score is appropriate. No additional parameter information could be added in the 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 clearly states the resource ('company information for Everstake') and enumerates the specific content areas (overview, metrics, certifications, products, clients, contact details). It distinguishes itself from sibling tools that target a single dimension by positioning itself as the comprehensive aggregate, so an agent can tell it apart without reading each sibling's schema.

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

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

It provides an explicit condition: 'Use when users need comprehensive facts about Everstake as a company.' This tells when to select this tool over more specialized siblings. It doesn't explicitly mention when not to use it or name alternatives, but the condition is clear enough for an agent to route correctly. A 4 is appropriate since no exclusions or alternative names are given, but the context is solid.

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, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context by specifying the content scope: social media, company resources, and purpose-specific contact channels.

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: the first states the tool's content, and the second states when to use it. No filler or redundant wording, though 'Comprehensive' is mildly promotional.

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

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

For a zero-parameter, read-only informational tool, the description fully covers what the tool provides and when to invoke it. There is no missing operational detail needed to select or call 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?

The tool has zero parameters, so the description does not need to explain parameter meaning. The schema is empty and requires no additional semantic clarification.

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

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

The description clearly identifies the tool as a source for Everstake contact information and routing, with content including social media, company resources, and purpose-specific channels. It is distinct enough from siblings like get_company_profile, though the mention of 'company resources' introduces some overlap.

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 when users need to contact Everstake or find specific company resources.' It does not explicitly mention alternatives or when not to use it, but the usage context is clear and unambiguous.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds content-level context but no additional behavioral detail such as response format, filtering, or access considerations. This is acceptable given the annotations.

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

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

Two concise, front-loaded sentences: the first states the resource, the second states the usage trigger. No filler, no redundancy, and 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 parameterless, read-only documentation retrieval tool, the description covers the resource and the main use cases. There is no output schema, but the nature of the tool makes the return content fairly predictable. A brief note on what the response contains would make it fully complete.

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

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

The tool has zero parameters, so there is no parameter semantics burden on the description. The schema coverage is effectively complete at 100% with no params to document, matching the baseline for parameterless tools.

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

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

The description clearly identifies the tool as the source for developer resources, SDK documentation, integration guides, and API references specific to Everstake. It is distinct enough in resource type, though it does not explicitly contrast with the overlapping sibling get_integrations.

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

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

It explicitly states when to use the tool: 'when developers need SDK documentation, integration guides, API references, or technical implementation details.' It does not mention when not to use it or name alternatives, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so this is clearly a safe read operation. The description adds no additional behavioral context such as auth requirements, rate limits, or data freshness; for a simple informational tool this is acceptable but not enriched.

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 focused sentences: the first defines the content scope and the second states the usage trigger. Every word earns its place, with no filler or repetition of the tool name.

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

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

For a no-parameter, read-only informational tool, the description adequately covers what will be returned (categories of integrations) and when to use it. It does not specify output format or pagination, but with no output schema and no parameters, this is a minor gap rather than a functionality risk.

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

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

The input schema has zero parameters, making schema description coverage trivially complete. The description adds no parameter-level semantics because none are needed; with no parameters, the baseline of 4 is appropriate.

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

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

The description clearly identifies the tool's resource: integration information for Everstake, enumerating custody platform integrations, wallet partnerships, and developer SDKs. It is specific enough to distinguish from siblings like get_developer_docs and request_integration, though it relies on a noun phrase rather than an explicit verb like 'list' or 'retrieve'.

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 second sentence explicitly states when to use the tool: when users need details about integrating Everstake with existing platforms, custody solutions, or development frameworks. It does not mention exclusions or alternative sibling tools, so it stops short of full when-not guidance.

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

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

Annotations already cover the read-only, idempotent, non-destructive profile, so the description does not need to repeat that. It adds light behavioral context by describing the type of information returned, but it does not reveal details like response format or whether data is static or live.

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

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

The description is two sentences with no filler. The first sentence states the tool's content scope, and the second provides a direct usage cue. Every clause 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 zero parameters, rich annotations covering safety, and a simple informational purpose, the description is largely sufficient. It could be slightly stronger by naming how it differs from sibling information tools or by indicating the return shape, but nothing critical 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?

There are no parameters, and schema_description_coverage is 100%. With zero parameters, the description is not expected to explain parameter meaning; the baseline of 4 applies.

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

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

The description clearly identifies the resource as 'Everstake's product offerings' and lists concrete content areas (features, use cases, pricing, technical specifications). It does not explicitly distinguish itself from sibling tools like get_solutions or get_integrations, so it stops short of full differentiation.

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

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

The description explicitly says when to use it: 'when users need specific product details for decision-making or integration planning.' It gives a clear usage context, though it does not state exclusions or mention alternative sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds content scope but does not disclose behavioral details such as how current the information is, whether it is static, or the structure of the returned data. This is acceptable but not rich.

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

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

Two concise sentences with no filler. The first sentence front-loads the tool's subject and content, and the second provides usage guidance. 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 read-only, zero-parameter lookup tool, the description adequately explains what is returned and when to use it. It lacks explicit return-structure detail, but given the low risk and simple invocation, this is a minor gap rather than a critical omission.

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

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

The tool has zero parameters, so the description has no parameter semantics to add. Per the baseline for no-parameter tools, this is appropriate and complete.

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

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

The description states a specific verb ('get'), a specific resource ('security profile'), and enumerates concrete content categories: certifications, audits, infrastructure security, and compliance standards. This clearly distinguishes it from sibling tools like get_company_profile and get_contact_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 to use the tool when users need security details, compliance verification, or trust/safety information. It does not mention exclusions or alternatives, but the context is clear enough for a zero-parameter informational lookup.

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 cover the safety profile: readOnlyHint, idempotentHint, and destructiveHint=false. The description adds no behavioral detail beyond content focus, which is acceptable given the strong annotation coverage, but it does not disclose return behavior or limitations.

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 filler. The core value proposition is front-loaded with the client segments, followed by a clear usage directive.

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

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

For a zero-parameter, read-only informational tool, the description fully equips an agent to decide when to invoke it. No output schema is present, but the tool's content and purpose are sufficiently clear for correct 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?

The tool has zero parameters, so the schema fully defines the input surface. The description's mention of client segments implies what content might be relevant, but with no parameters there is little to add; baseline for zero-parameter tools is 4.

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

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

The description names a specific resource—industry-specific solutions and integration approaches—and enumerates the client segments covered. It distinguishes itself from sibling tools like get_integrations by emphasizing tailored, segment-specific guidance rather than a generic list.

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

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

It provides explicit when-to-use guidance: when users need tailored solution guidance for their business type or integration scenario. It does not mention when not to use it or name 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds the 'Everstake services' scope but does not disclose return format, time range, or any other behavioral detail. Given the annotations cover the main safety traits, a neutral 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 a single concise sentence with no redundant words. It front-loads the purpose immediately and does not waste tokens on obvious or irrelevant details. For a zero-parameter read-only tool, this level of brevity is appropriate.

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

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

With no output schema, the description carries some burden to explain what the tool returns, but it only says 'uptime metrics' without specifying metric types, time ranges, or response shape. Annotations clarify safety and the empty schema removes parameter concerns. The description is minimally viable but leaves an agent guessing about the exact data it will receive.

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

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

The input schema has zero parameters, so there are no parameter semantics to document. The description correctly stays silent on parameters, and the baseline for a parameterless tool is high. It does not need to add anything beyond what the schema already conveys.

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

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

The description states a clear resource ('uptime metrics for Everstake services') and the action ('Provides'), which is sufficient to identify the tool's core purpose. It does not explicitly distinguish from siblings, but no sibling covers uptime metrics, so the resource itself is differentiating. The wording is somewhat generic and closely mirrors the tool name, preventing a top score.

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

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

The description implies when to use the tool: when uptime metrics for Everstake services are needed. It provides no explicit when-not-to-use guidance or alternatives, but the sibling list contains no competing uptime metric tool, so the lack of exclusions is less critical. The guidance remains mostly implicit rather than explicitly stated.

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 openWorldHint=true and destructiveHint=false, so the agent knows this is a safe side-effecting action. The description adds context beyond that: submissions are routed to Everstake's sales team via Pipedrive CRM, and lead_source is set automatically. It also discloses the failure fallback. This is useful behavioral context, though it doesn't specify the exact response or further side 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?

Four sentences with no fluff. The main purpose is front-loaded, and the operational notes are concise. It's slightly longer than the bare minimum but every sentence carries operational weight.

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 14-parameter submission tool with no output schema, the description covers the essential operational aspects: required fields, optional field collection, the auto-set lead_source, and a fallback. It doesn't specify return values, but that's often acceptable. The description is sufficiently complete for an agent to execute the workflow 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% and each parameter includes detailed enumerations (e.g., custody_solution, product_of_interest). The description adds value by instructing the agent to collect required fields conversationally and to gather optional fields where available, plus explicit guidance that lead_source should not be asked. This goes beyond what the schema states.

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

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

The description opens with a specific verb and resource: 'Submit an integration or staking inquiry on behalf of a user.' It clearly states the action and the subject. The sibling tools are all read-only (get_*) or calculative (staking_calculator), so this stands out as the only submission tool. The scope is unambiguous.

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

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

It explicitly states when to use: 'Use when a user expresses intent to integrate with Everstake, explore staking services, or request more information about products.' It also gives operational guidance: collect required fields conversationally, don't ask for lead_source (auto-set), and provides a fallback URL if submission fails. This covers both when and how, with an explicit alternative.

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 read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond those hints: the dependency on get_chains networks, daily APY updates, and the interactive estimation nature. No contradiction with annotations.

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

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

The description is compact and front-loaded, with the core purpose in the first sentence and key constraints in the following lines. The final 'MUST HAVE either currency or chain set' sentence is redundant and inaccurate, slightly reducing the overall quality, but the structure remains 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 read-only estimator with no output schema, the description covers purpose, inputs, expected outputs, the get_chains dependency, and data freshness. The response shape is not described in detail, but the stated outputs (annual and monthly rewards) are sufficient. The inaccurate requirement line prevents a higher score.

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

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

Schema coverage is 100%, so the baseline is 3, but the description actively misleads about parameters: it states 'MUST HAVE either currency or chain set' while the schema requires network, currency, and amount. It also omits currency when explaining inputs. This incorrect guidance drops the score below baseline.

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

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

The description clearly identifies the tool as a staking reward estimator and specifies the key inputs and outputs: network and stake amount yield estimated annual and monthly rewards based on current APY. It is distinct from sibling tools like get_chains and other read-only get_* tools, though it lacks an explicit action verb.

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 restricts usage to networks provided by get_chains, effectively telling the agent to call get_chains first. It also conveys the expected inputs and data freshness. However, the 'MUST HAVE either currency or chain set' instruction is inaccurate because the schema requires network, currency, and amount, and 'chain' is not a parameter.

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