santyvv-data — market & on-chain data

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

Annotations already mark the tool as read-only, and the description adds useful context: it covers the server's tools and HTTP routes and is free. It does not describe the exact output format, but for a parameterless catalog this disclosure is sufficient and consistent with 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 short, information-dense sentences with no filler. The key facts are front-loaded, and 'Gratis' adds a useful cost qualifier at the end without bloating the 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?

For a parameterless, read-only catalog tool, nothing essential is missing: content scope, cost, MCP tool coverage, and HTTP route equivalence are all stated. Although there is no output schema, the description gives enough shape to the expected informational response.

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 an empty input schema, so there is no parameter burden for the description to carry. The description still adds value by indicating the kind of information returned: what can be requested, the price, and the name.

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's purpose: it tells the agent what can be requested, at what price, and under what name. It also explicitly says it includes all MCP server tools and their equivalent HTTP routes, which distinguishes it from the functional 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?

The description gives clear context: this is a discovery/meta tool for identifying available tools, costs, and naming, including HTTP equivalents. It does not explicitly state when to prefer alternatives or list exclusions, but the intended use is evident and not merely implied.

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

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

Annotations already indicate read-only and open-world behavior, and the description adds valuable detail: it performs a live test, returns HTTP status and latency, and is free. This goes beyond the schema and annotations to set accurate expectations about what the tool actually does.

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 focused sentences deliver the action, outputs, cost model, and use cases with no filler. Key behavioral information is front-loaded.

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 diagnostic tool with no output schema, the description is complete: it explains what is tested, what is returned, and when the tool is useful. Nothing essential is missing for an agent to decide to call 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?

There are zero parameters and the schema coverage is 100%, so no parameter documentation is needed. The description correctly implies this is a simple, unparameterized probe rather than a configurable query.

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 action ('Prueba en vivo'), a clear resource ('cada fuente publica que respalda los datos'), and the concrete outputs (respuesta, estado HTTP, latencia). This distinguishes it from the data-querying sibling tools, making its diagnostic role immediately clear.

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

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

The description gives explicit when-to-use guidance: use it for free to decide whether a paid query is worth it or to identify where a datum came from. It does not explicitly name an alternative tool or state when not to use it, but the context is clear enough.

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 read-only annotation already covers safety, and the description adds value by disclosing the cost ($0.03 per call), the payment asset (USDC on Base), and the x402 protocol. It also lists what the response will describe, which is helpful since no output schema exists. It does not contradict 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?

Three short sentences, each earning its place: what the ficha contains, when to use it, and what it costs. The most identifying information is front-loaded, and there is no repetition of schema or title 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 covers the returned contents and adds cost/context. The main missing piece is an explicit note about the batch limit or the comma-separated format, but the schema provides that, so the description is largely 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%, so the baseline applies: the chain enum and tokens field are already documented in the schema. The description adds no new parameter-level meaning. There is a schema inconsistency between maxLength 42 and the 'up to 10 addresses' claim, but the description itself does not address or worsen it.

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 resource: a token's identity and value, enumerating name, symbol, decimals, supply, contract, and price. It also adds a specific use case—checking whether an address is a real contract. It does not explicitly distinguish itself from siblings like precio or catalogo, but its content makes the differentiation fairly obvious.

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 'Sirve para saber si una direccion es un contrato real y que representa' gives a clear intended use case. It does not mention alternatives or when not to use the tool, but it provides enough contextual guidance for an agent to select it appropriately.

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 doesn't need to repeat that. It adds the cost per call ($0.03) and payment method, which is valuable behavioral information beyond the annotations. It doesn't mention rate limits or return format, but the output is described in the first sentence.

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-loading the core functionality in the first sentence and adding context and cost in the second. 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?

The description lists the exact outputs (total market cap, Bitcoin dominance, etc.), mentions cost and payment method, and clarifies its scope. With only two optional parameters, this 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?

Both parameters (vs and limite) have descriptions in the schema, and the schema coverage is 100%. The description does not add any parameter-specific details, so the 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 provides general market status: total capitalization, Bitcoin dominance, 24h change, top coins by market cap and movers. It explicitly distinguishes itself from a tool for a specific asset, which helps differentiate from siblings like ficha_token or precio.

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 it's the context question, not a specific asset, which implies when to use it (general market overview) and when not (specific asset queries). However, it doesn't explicitly name alternative tools or give more detailed usage conditions.

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 mark the tool read-only, and the description adds valuable behavioral context: the price is real-time, computed as a median across venues, includes divergence, and costs $0.02 per call in USDC on Base via x402. It does not detail the exact response format or rate limits, but this is still a strong disclosure 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 three tight sentences: value proposition first, then methodology and use cases, then cost. Every sentence carries useful information and there is no filler or repetition of schema 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 read-only single-parameter tool, the description covers purpose, behavior, output concept, and cost. It lacks an exact JSON response shape and explicit sibling routing, but those are minor given the simple interface and fully documented 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 input schema fully documents the only parameter, symbols, including format, example, default, and a stated maximum of 20 comma-separated symbols. The description itself adds no parameter-level detail, so the high schema coverage baseline of 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 that the tool returns a cryptoasset's current USD value as a median across exchanges, with divergence, and explicitly says it is not a single-venue quote. It also lists concrete use cases: quoting, comparing, and detecting misaligned venues. This gives a specific resource and behavior and differentiates it from a plain single-exchange price 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?

It provides clear usage contexts: cotizar, comparar, and detectar plazas desalineadas, and it also discloses the per-call cost so an agent can weigh whether to invoke it. However, it does not name sibling tools or state when not to use it, so explicit alternative/exclusion guidance is missing.

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 mark the tool as read-only, and the description adds meaningful context: the optional-token behavior and the $0.03 per-call cost paid in USDC on Base via x402. No statement contradicts 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?

Three short sentences: core behavior first, then use case, then cost. There is no filler or redundant repetition of the schema.

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 the return concept, use case, and payment context, and the schema documents address pattern and chain enum. However, there is no output schema, so return formatting is underspecified, and the unresolved token-required/optional contradiction leaves an agent unsure whether a native-only call is valid.

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 would be 3, but the description and schema contradict each other on requiredness: the schema lists 'token' under required while both the description and the token property call it optional. This makes the actual calling contract unclear and outweighs the value of the schema descriptions.

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 'Cuanto tiene una direccion' and precisely states what the tool returns: the network native balance and, conditionally, an ERC-20 balance with its decimals. This is a concrete resource-and-result statement that clearly separates 'saldo' from the price, market, and catalog 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?

'Sirve para verificar pagos o tenencias sin abrir un explorador' gives an explicit use case. It does not name alternatives or exclusions, but the main when-to-use context is clear enough for an agent to select 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?

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context beyond that: the per-call cost ($0.01), payment method (USDC on Base via x402), and that it returns both current TVL and variations. No contradictions 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?

Three short, front-loaded sentences. The first states the core function, the second gives usage rationale, and the third covers cost and settlement. No redundant 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?

For a simple one-optional-parameter read-only tool, the description plus schema covers what it does, what it returns, when to use it, and even cost details. Nothing essential 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?

Schema description coverage is 100% and the 'protocol' parameter is already documented with an example ('aave'). The description adds no extra parameter detail, so a 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 states a specific action (measuring deposited funds) and resource (a DeFi protocol) with concrete output details (TVL in USD, 24h and 7d variation). This clearly distinguishes it from siblings like precio or saldo.

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 a clear usage context: 'Es la medida de tamano y salud de un protocolo antes de interactuar con el.' This tells the agent when to use it but does not explicitly name alternative tools 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?

Annotations already declare readOnlyHint and openWorldHint, and the description adds useful context: a $0.01 per-call cost in USDC on Base via x402, plus no exchange key requirement. However, it states an interval range of '1m a 1d' that conflicts with the schema's accepted 1w and 1M values, which undermines behavioral 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?

The description is three sentences: core function, use cases, and cost/payment details. It is well front-loaded and contains no filler, but the inaccurate interval parenthetical keeps it from being flawless.

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 3-parameter tool, the description covers purpose, when to use it, keyless access, and cost; the title supplies the OHLC return concept and the schema covers parameter mechanics. The interval mismatch is the main gap, but an agent still has enough information to select and invoke 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%, with defaults, an example symbol, and the interval enum fully documented, so the baseline is 3 even though the description adds no new parameter detail. The parenthetical '1m a 1d' is also slightly inconsistent with the enum, preventing any bonus.

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: latest OHLC candles for a trading pair ('Las ultimas velas de un par con el intervalo que se pida'), which is specific enough to distinguish it from a single price point. It lacks an explicit verb and does not explicitly differentiate from siblings like 'precio' or 'mercado', but the title and description together make the operation obvious.

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?

Sentence two explicitly ties the tool to trend/volatility calculations and charting without an exchange key, giving clear use cases. It does not mention when not to use it or name alternative tools, but the context is clear enough for an agent to decide when this tool is relevant.

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