dex-data
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Tools are mostly distinct with detailed descriptions, but there is overlap among DEX-related tools (e.g., get_liquidity, get_pool_reserves, get_slippage, get_liquidity_risk, find_arbitrage, get_best_venue, get_dex_spread) that could cause confusion. The extensive descriptions mitigate this, but not entirely.
Naming Consistency3/5Naming is inconsistent across tools: many use 'get_' (get_token_price, get_liquidity, get_gas) but others use different verbs (find_arbitrage, list_chains, read_feed, geolocate_ip, lookup_lei, url_to_markdown, geocode, reverse_geocode, search). The pattern is not uniform, though within groups it is consistent.
Tool Count2/5The server is named 'dex-data' but includes 23 tools, many of which are unrelated to DEX (weather, holidays, random, search, LEI lookup, treasury yields, IP geolocation). This suggests scope creep and a mismatch between the name and the toolset, making the count feel excessive for the stated purpose.
Completeness4/5For the broad domain implied by the actual toolset (covering DEX, gas, weather, news, geolocation, financial data), the coverage is fairly comprehensive. However, if the intended domain is strictly DEX data, there are missing features like historical price data or order book depth, but given the mix of tools, completeness is good overall.
Average 4.3/5 across 23 of 23 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 37 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention side effects, permissions, rate limits, or whether the tool is read-only. It is likely a read-only query tool, but this is not disclosed, leaving the agent without full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using only two sentences to convey the core functionality and expected outputs. It avoids unnecessary detail and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions key outputs (cross-venue spread in bps, fee-adjusted arbitrage spread) but does not specify the exact structure of the return value. Since there is no output schema, this is sufficient for a simple query tool, though slightly more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions (pair as SYM/SYM, chain with enum and default), providing 100% coverage. The descriptions are minimal but adequate. The main description adds no additional per-parameter context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: identifying the cheapest DEX to buy and the most profitable to sell for a given pair, while also providing cross-venue spread and fee-adjusted arbitrage spread. This is specific and distinguishes it from similar sibling tools like get_dex_spread or find_arbitrage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for smart order routing and comparing venues, but it does not explicitly state when to use this tool over alternatives such as get_dex_spread or get_pool_reserves. The differentiation is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently discloses that results are ranked by gross USD at optimal trade size, not raw spread, that an empty list is a valid result, and that gas, MEV, and execution risk are excluded. This provides clear behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and each sentence adds value: it defines the scope, the ranking method, the empty-list behavior, and the exclusions. It is slightly verbose but not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description indicates the output is a ranked list of opportunities and explicitly states the empty-list case. It also clarifies what is excluded, giving enough context for an agent to interpret results. Minor gaps remain about the exact output format or fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for parameters, each with a description (chain, minSpreadBps). The tool description adds context about ranking by gross USD, but does not add significant new meaning to the parameters beyond what is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans a chain for cross-venue arbitrage opportunities, using the specific verb 'scan' and resource 'chain'. It differentiates from siblings like get_dex_spread and get_best_venue by focusing on a cross-venue, chain-wide scan rather than a specific pair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'right now' indicating real-time scanning, but does not explicitly state when to prefer this tool over alternatives such as get_dex_spread or get_best_venue. Some guidance is implied by the scope (chain-wide vs. specific pair), but it is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention whether the operation is read-only, any side effects, authentication requirements, rate limits, or error behavior. Given the lack of annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and efficiently packs the tool's purpose and key output details without any redundant or promotional language. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description outlines the nature of the return data (per-venue depth, TVL, best venue, share of total depth), which is helpful given the absence of an output schema. However, it omits details such as expected format, units, or any caveats about data freshness or availability, though the absence is not critical. Overall it provides sufficient context for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema. 'pair' specifies the format (SYM/SYM) with a concrete example and notes that either side may be a 0x address. 'chain' provides an explicit enum of allowed values and a default. The schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns market depth and TVL for a trading pair, per venue, and explicitly lists the key outputs (pool depth, best venue, share of total depth). The verb 'get' and resource 'liquidity' are unambiguous, and it distinguishes itself from the many sibling tools that focus on a single venue or different metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to choose it over similar siblings like 'get_pool_reserves' or 'get_best_venue'. It implies use for per-venue liquidity breakdowns, but this guidance is implicit rather than explicit, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly states the tool returns data ('Returns gas price in gwei') and emphasizes 'Live gas prices', indicating a read-only, informational operation with no destructive side effects mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description repeats the same sentence structure twice (listing gwei, base fee, and USD costs), making it more verbose than necessary. It could be trimmed to a single clear statement without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description enumerates the exact returned fields (gas price in gwei, base fee, USD costs for transfer/ERC-20/swap) and the ordering behavior, giving an agent sufficient context to correctly use the tool and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with an enum and description. The description adds value by clarifying that omitting the chain defaults to 'all' and that results are ranked cheapest-first, enhancing the schema's basic enum listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves live gas prices across multiple specific chains (BNB Chain, Polygon, Arbitrum, Base, Avalanche, Optimism) and outputs them ranked cheapest-first, which differentiates it from pricing, liquidity, and venue tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bridging, routing, and execution timing, but does not explicitly state when to prefer this tool over alternatives like get_token_price or get_slippage. The context is present but could be more direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that it is not a ranking and that it filters out dropped terms, and it explains the output format (suggestions, questions, comparisons). It does not mention rate limits or API-side behaviors, but the data-processing transparency is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and relatively concise, though it uses dense phrasing like 'live search autocomplete, expanded across question modifiers'. It stays focused on the tool's function and output without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description explains the return structure ('split into suggestions, questions and comparisons') and the filtering behavior, which is sufficient for an agent to understand what the tool will produce. It lacks explicit examples or edge-case handling, but covers essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameter descriptions, so the description adds no extra value for parameters. It merely restates the schema's semantics (e.g., 'expanded across question modifiers' relates to depth, but this is not explicitly linked). The baseline for high schema coverage is 3, and the description does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to retrieve search autocomplete suggestions for a topic, expanded across question and comparison modifiers. It explicitly differentiates it from ranking tools, calling it 'a demand signal for content and keyword research, not a ranking', which distinguishes it from siblings like 'search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies when to use the tool (for demand research) and notes that rows where the engine dropped the term are filtered out, giving insight into data handling. However, it does not explicitly mention alternative tools or provide a direct 'use this when' statement, though the context makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses behavior: returns clean JSON, includes date normalization, null for unparseable dates, summaries in HTML and plain-text, and 'real destination link' implying redirect resolution. Missing auth/rate-limit details but these may be irrelevant for a read-only public feed tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a few sentences but dense with useful information, front-loading the purpose and then detailing output structure and date handling. No fluff, though it could be slightly more concise without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description is fairly complete: it explains the output structure, date behavior, and even mentions a sibling tool. It doesn't cover error scenarios or edge cases (e.g., invalid URL), but these are not critical for a read-only feed fetcher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the baseline is 3. The description does not add extra meaning beyond the schema; it mentions the URL type but does not elaborate on limit or its default. Since the schema already documents them, this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear verb 'Read' and resource 'any public RSS, Atom or RDF feed' and specifies output as clean JSON with feed and item fields. It distinguishes itself from url_to_markdown by noting it reads the feed itself, not the linked article.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly pairs with url_to_markdown for reading linked articles, providing a clear alternative and context. However, it doesn't give explicit 'when not to use' conditions beyond that pairing, but the context is sufficient for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the analysis outputs: market classification, venue count, and flags for single-venue markets and wide spreads. It also clarifies it is liquidity depth analysis only, but does not describe any side effects or error behavior, which is acceptable for a read-only analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the tool's purpose and constraints without unnecessary detail. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides enough context for an agent to decide when to use it, including exclusions. It lacks details on classification thresholds or return format, and does not explain what constitutes a wide spread, but these are not essential for correct selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage for both parameters (pair, chain with enum and default), so the description adds no additional parameter semantics beyond the schema. Baseline 3 is appropriate since coverage is high and the description does not deepen parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action 'Pre-trade depth check' and resource 'pair', and explicitly distinguishes itself from contract audits and honeypot checks, making its purpose unambiguous. It also sets expectations by noting it is liquidity depth analysis only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage before trading, and clearly states what it is not ('NOT a contract audit and NOT a honeypot check'), which helps an agent avoid misusing it. However, it does not name alternative sibling tools for those excluded purposes, so the guidance is not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains what the tool returns (price, pair, liquidity, confidence) and a specific refusal case (dust pool). It does not cover all error scenarios, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and free of redundant information. It efficiently communicates functionality, inputs, outputs, and a key edge-case refusal in a single paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description adequately explains the return payload. It also mentions the refusal condition and input flexibility. It does not address potential errors (e.g., invalid token), but overall it provides sufficient context for an agent to decide and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions. The tool description adds value by providing concrete examples for token (CAKE, WETH, ARB) and clarifying that any contract address is accepted. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving live USD prices for ERC-20 tokens from DEX pools. It distinguishes itself from sibling tools like get_liquidity or get_best_venue by focusing on price with specific output details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides conditions for use (accepts ticker or contract address) and a refusal condition (dust pool), but does not explicitly contrast with alternatives or state when to prefer this tool over siblings. This leaves some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description openly states that the tool is free and local, indicating no side effects or network calls. It does not mention rate limits or other constraints, but given its read-only nature, the transparency 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, using a single sentence to convey the purpose and key attributes. Every word contributes to the meaning without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description fully covers its purpose, cost implications, and local execution. It provides sufficient context for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema is fully covered (100%), so the description adds no parameter-specific information. The baseline of 3 applies as there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reports the amount spent on paid calls and the active caps. It is specific and immediately understandable, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to check budget before incurring more costs) and notes it is free and local, but does not explicitly contrast with sibling tools or state a precise trigger condition. Still, the context is inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral aspects: results are ranked by name match, and lapsed/retired/annulled entities are flagged instead of filtered, with a note that a hidden record is indistinguishable from no record. This goes beyond basic functionality but does not cover pagination, error handling, or other edge-case behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It opens with the primary usage scenario, lists return fields in a single sentence, and adds a clarifying behavioral note. No unnecessary verbosity or confusing phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for an agent to understand the tool's purpose, inputs, and output fields. It lacks an output schema but compensates with a clear field list. It does not explicitly address when to use this tool vs. siblings, but the name-based lookup focus is implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (q, lei, limit) have clear, detailed descriptions covering purpose, constraints (max length, exact LEI format, range), and defaults. Schema coverage is 100% and each parameter's semantics are fully explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: looking up a company by name (or LEI) in the GLEIF golden copy, and explicitly contrasts it with identifier-based lookup. It also lists the exact fields returned, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for name-based lookups ('knowing the LEI already is the hard part') and notes that lapsed/retired entities are flagged rather than filtered. However, it does not explicitly state when to prefer this tool over sibling tools or provide decision criteria beyond the name-vs-identifier distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses cryptographic security, rejection sampling to avoid modulo bias, and output formats. This is transparent about the tool's behavior and guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but not overly long. It front-loads the core purpose and then details specifics, making it efficient to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description explains what is returned (integers or bytes in hex/base64) and the modes. This is adequate for an agent to understand the tool's output without further detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds crucial context: 'inclusive' bounds, default of 32 bytes, and that count applies only in integer mode. This clarifies parameter behavior beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides cryptographically secure randomness, either uniform integers in a range or random bytes in hex/base64. This distinguishes it from sibling tools that focus on data retrieval or calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions use cases like nonces, IDs, sampling, and shuffling, giving clear guidance on when to invoke. It does not explicitly mention when not to use, but the purpose is sufficiently specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses behavior: simulates against live reserves, reports price impact and fee separately, and explicitly states exclusions (gas, MEV, multi-hop). It does not explicitly state side effects (e.g., read-only), but the nature of a simulation query implies no destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and dense with relevant information: purpose, simulation mechanics, output details (fee reported separately), and scope exclusions. Every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: what it returns (price impact and fee), scope (pool-level), and exclusions. It does not mention error handling or output format, but no output schema exists and the tool's simplicity allows this to be sufficient. The 'every venue' phrasing could be ambiguous, but overall it provides enough context 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters described). The description adds crucial context beyond the schema: it clarifies the relationship between amountIn and amountUsd ('Required unless amountIn is given instead — slippage is meaningless without a size'), making the parameter semantics clearer than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to calculate price impact for a specific trade size, distinguishing it from spot price. It specifies the resource (slippage/price impact) and action (simulates swaps), and sets expectations by noting it reports fee separately and excludes gas/MEV/multi-hop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use it (when spot price is insufficient for a specific trade size) and provides scope limitations (pool-level only, excludes gas/MEV/multi-hop). It does not explicitly name alternative tools, but the context from sibling tools and the 'which a spot price cannot tell you' phrasing provides adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral disclosure burden. It reveals the return format (all maturities, spreads, inversion flag), the null handling for unpublished tenors, the non-publication day fallback to available range, and explicitly disambiguates the rate type (nominal CMT, not real or zero-coupon). This is comprehensive and leaves no critical behavior unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and well-structured, front-loading the core purpose and then adding important details about null handling and rate type. The conversational aside ('because the real question...') adds character but is slightly tangential; still, the overall length is acceptable and every substantive detail earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 is complete: it specifies all return components, edge cases, and data semantics. An agent can accurately predict the tool's behavior and results without needing additional context. There are no missing elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description already explains the format, default, and non-publication behavior. The tool description adds no new parameter-level information beyond what the schema provides, so the baseline of 3 is appropriate. It does not need to compensate because the schema is already explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: retrieves the US Treasury par yield curve for a given business day, enumerating the exact outputs (all constant-maturity rates, spreads, inversion flag). It is clearly distinct from all sibling tools, which deal with crypto, geolocation, or other domains, so there is no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While there are no closely related sibling tools to contrast, the description gives explicit usage context: it specifies the date parameter behavior, explains that unpublished tenors are null rather than zero, and clarifies that these are nominal CMT rates, not real or zero-coupon yields. This effectively tells an agent when and how to interpret the results, though it does not 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a key behavioral edge case: ocean/unmapped coordinates return 404 and never fabricate an address. This exceeds basic annotation coverage and sets accurate expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences fully convey purpose and critical behavior without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for an agent to understand the tool's function and main limitation, though it does not specify output format or exact response shape. Given the simple input schema and clear purpose, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with ranges; the description adds the semantic purpose of these coordinates in the context of reverse geocoding, slightly enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Convert') and resource ('latitude/longitude coordinates' to 'nearest street address and place name'), and differentiates from sibling 'geocode' by specifying reverse geocoding via OpenStreetMap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly describes the tool's purpose and distinguishes from the forward 'geocode' sibling implicitly. It does not explicitly state when not to use it, but the context and wording make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description clearly discloses return content, the 404 failure mode, and the guarantee of never guessing coordinates. It does not mention rate limits or authentication, but these are less critical for a simple read-only geocoding tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, all informative, with no redundant or filler content. Key constraints (worldwide, via OpenStreetMap, no guessing) are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and clear return/failure semantics, the description covers everything an agent needs to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single query parameter, and the description adds a concrete example ('Eiffel Tower, Paris') plus clarifies acceptable input types (address, city, place name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Convert') and resource (street address/city/place name to coordinates), and clearly distinguishes itself from siblings like reverse_geocode and geolocate_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly conveys forward geocoding usage through its resource description and return values, though it does not explicitly name alternative tools or conditions for 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently enumerates the returned data (balances, fee, price, TVL, block height) and the scope (every venue). It does not mention read-only behavior explicitly, but that is implied by the nature of querying reserves, and the description is sufficiently transparent for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, tightly packed with relevant information: what data is returned, the scope, and a usage directive. No redundant or filler content; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates by fully listing the return fields (balances, fee, price, TVL, block height) and the aggregation across venues. It also provides context on how this data relates to other tools, making it complete for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description for 'pair' and 'chain' in the schema already provide clear definitions and examples; the tool description adds no further semantic detail beyond what is already in the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' with resource 'pool reserves' and scope 'for a pair on every venue'. It also differentiates from sibling tools by noting this exposes raw data underlying the price, depth, and slippage tools, and directs users who want to do their own calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool: 'use it when you want to do your own maths rather than take ours.' This gives clear guidance on alternatives and the context for selection, satisfying the criteria for usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the data is a model forecast and not a station reading, and notes that the response will indicate this. It does not mention side effects or read-only nature, but for a simple 'get' tool this is adequate. Since no annotations are provided, the description carries the burden and covers the most important behavioral aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundancy or fluff. It efficiently conveys the core purpose, output contents, a clarifying note, and usage guidance without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description explicitly lists the output fields (temperature, feels-like, humidity, precipitation, wind speed/gusts, daily highs/lows, precipitation probability). This gives a comprehensive understanding of what to expect, and the geocode note provides necessary context for input handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for lat, lon, and days (coverage 100%). The tool description repeats these descriptions without adding extra meaning such as units or default behavior beyond what the schema already states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides current weather and a 7-day forecast for coordinates, and explicitly distinguishes it from station readings and directs users to geocode for place names. This leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use the geocode tool first when a place name is provided instead of coordinates, providing clear when-to-use and when-not-to-use guidance. No other weather siblings exist, so no alternative is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral transparency burden. It discloses the extraction method (Firefox reader-mode rules), the PDF text-layer behavior with page count, and the typed errors (no_text_layer, not_extractable) for edge cases. This gives the agent a complete picture of expected outcomes and failure modes, exceeding what a typical description provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and output, and each sentence adds essential information (what it does, how it handles HTML/PDF, and error behavior). There is no fluff or repetition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is remarkably complete. It covers the input, the output structure (Markdown plus metadata), the processing method, and specific error cases. Nothing an agent needs to know to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of the single parameter 'url' with a clear description: 'Public http(s) URL of an article or PDF.' The tool description repeats the same information without adding new semantics or examples, so it adds minimal value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: fetching a public article or PDF URL and returning clean Markdown plus metadata (title, byline, site name, word count). It distinguishes from siblings like read_feed by specifying the Markdown conversion output and error handling, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (whenever a URL needs to be converted to Markdown), and notes that it handles both HTML and PDFs. It does not explicitly mention alternatives or when not to use it, but the clear purpose and specific error cases provide sufficient usage context without needing explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It transparently explains weekend/holiday counting, year-boundary walking, whole-year behavior, and exclusions. It could go further by describing the exact response shape or edge cases such as invalid input, but for a read-style holiday tool the behavior is disclosed well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, all earning their place: the first states the core purpose, the second covers date mode, the third covers year mode, and the fourth names exclusions. The most important information appears first and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and the absence of an output schema, the description supplies the key return semantics: whether a date is a business day, next/previous business days, whole-year data without a date, and regional observation details. It also explicitly disclaims unsupported cases, making the tool safe to select in mixed contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes each parameter, which justifies a baseline of 3. The description adds useful parameter-level meaning beyond the schema: date triggers business-day calculations including year boundaries, and omitting date returns the entire year with regional observation details. That exceeds the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource (public and bank holidays for 100+ countries) and the concrete operations: determining whether a date is a business day and finding next/previous business days. It also distinguishes its scope from sibling tools by explicitly marking what it does and what it does not cover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives two explicit invocation modes: pass a date for a business-day answer, or omit a date to get the whole year. It also clearly states exclusions, warning that regional closures, half-days, and market trading calendars are not covered. No competing holiday/business-day sibling exists, so the guidance is complete enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool is 'Free' (a cost trait) and implies a read-only list operation. However, it doesn't detail potential side effects, rate limits, or response structure. Given the simplicity of a parameterless listing tool, this is adequate, but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single sentence that front-loads the main purpose ('Supported chains, their indexed tokens and venues') and then provides usage guidance. There is no redundancy or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description tells the agent what the tool returns (chains, tokens, venues) and when to use it. This is sufficient for the agent to decide to call it without additional details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so schema coverage is trivially 100%. The description doesn't need to explain parameters; instead it describes the resource output, which is the relevant information for the agent. This meets the baseline for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists supported chains, their indexed tokens, and venues. It uses a specific verb ('list') and resource ('supported chains, indexed tokens, venues'), and distinguishes itself from siblings by positioning as the first call for disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'the right first call if you are unsure which chain or ticker to use.' This provides clear usage context and differentiates it from sibling tools that answer specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral safety profile, and it exceeds expectations: it states count is a maximum not a guarantee, unresolved destinations are dropped rather than guessed at, sponsored rows are excluded, and results are not fetched or verified. These precise edge-behaviors are exactly what an agent needs to call it blindly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is two sentences with no filler: it front-loads the exact resource and action, then packs edge cases and usage notes briefly. The 'pair with' instruction at the end earns its place as it improves agent execution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still explains exactly what the returned results look like (title, real URL, display URL, snippet), what they exclude, and what happens in the face of unresolved destinations. It also names the natural next step (url_to_markdown). This is complete for a simple two-parameter search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes 'q' and 'count' with ranges and defaults, so the description does not need to add every edge. It adds meaningful contract beyond the schema by explaining that the declared number of results is a cap, not a promise, and why fewer results may be returned. That is more than a baseline, but the parameter descriptions themselves are already strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with 'Web search — a free-text query returns ranked organic results', which is a specific verb+resource+outcome. It details the result fields, excludes sponsored arrays, and states the hard limit of up to 25, clearly setting it apart from siblings like get_search_suggestions and url_to_markdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context on when this tool is used ('free-text query', returns ranked organic results) and explicitly routes follow-up consumption to url_to_markdown. It does not provide explicit 'don't use this when...' statements for similar alternatives like get_search_suggestions, so a small inference remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: it explains that detection result is prioritized, that unknown detection is possible ('never clean' means it won't falsely claim a clean status), and that coordinates are a centroid, not an exact location. This transparency is excellent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet comprehensive. It packs essential information (output fields, detection logic, limitations) into three sentences, each serving a clear purpose, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates by enumerating the specific data fields returned (country, region, city, postcode, coordinates, timezone, ASN, org, ISP). It also explains the additional detection field and its role, making the tool's behavior fully understandable without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'ip', is fully described: it accepts public IPv4 or IPv6 addresses and explicitly states that private and reserved ranges are refused. This covers both format and constraints, leaving no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: locating a public IPv4 or IPv6 address and returning detailed location and network information. It explicitly lists the output fields (country, region, city, etc.), making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage guidance by noting that detection of datacentre/VPN/proxy/Tor is returned first and that this determines the reliability of the location. It also cautions against interpreting IP coordinates as the exact physical location of a person, which helps set expectations. However, it does not explicitly compare with sibling tools or state when to prefer this tool over others, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden and does so well: it discloses cost, wallet requirement, and that it spends nothing without a funded wallet. It also enumerates the returned data, making side effects and behavior transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense run-on but packs all essential information up front (cost, purpose, parameters, wallet, alternatives). It is longer than necessary but organized in a natural flow from cost to functionality to requirements to alternatives, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description thoroughly covers inputs, outputs, costs, prerequisites, and alternative tools. An agent has enough context to decide whether to call this tool and what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so baseline is 3. The description adds value by providing example formats (WBNB/USDC) and clarifying that the first symbol is the USD-priceable side, and explaining fee tiers and omission behavior. Slightly redundant with schema but enhances usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides real-time cross-DEX price and spread for BSC across specific venues, plus best buy/sell venue, gross arbitrage spread, optimal trade size, liquidity, and block number. Explicitly contrasts with cheaper alternatives get_liquidity and find_arbitrage, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes it is paid ($0.01 USDC/call, no free tier), requires a funded wallet, and without one returns payment instructions and spends nothing. Directly tells when to use the free alternatives instead, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md: