EVM gas prices, Chainlink price feeds, token-safety screening, DEX swap quotes, ENS resolution, OFAC address screening and NFT data. Pay-per-call in USDC on Base via x402 — no signup, no API keys.
Screen a crypto address against the full live OFAC SDN list, segmented by chain. Returns a verdict with the matching SDN entries as evidence — never a silent all-clear. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Which chain the address belongs to. | base |
| address | Yes | The address to screen, in that chain's native format. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral guarantee ('never a silent all-clear'), the payment flow (call without x_payment to get terms, then with x_payment to get data), and the live nature of the SDN list. It does not cover error cases or rate limits, but the essential behaviors are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and is appropriately sized at three sentences. The payment flow is described in a dense, run-on sentence but every clause carries essential information. Slightly more structure would improve readability, but it is not verbose.
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 core function, return behavior, and the paid payment workflow, which are the major contextual elements. There is no output schema, so the explicit mention of the verdict and evidence is valuable. It lacks details on invalid addresses or network failures, but the description is sufficiently complete for a screening tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of 'segmented by chain' and the payment flow adds some context, but the schema already fully documents each parameter's meaning. The description does not add significant semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Screen a crypto address against the full live OFAC SDN list.' It also mentions the return of a verdict with matching SDN entries as evidence, clearly distinguishing it from sibling tools like gas_price or token_safety.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on the two-step payment process and explicitly names the 'pricing' tool as a free alternative for price discovery. However, it does not explicitly contrast with sibling screening tools (e.g., token_safety, nft_scam_check) or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Canonical record for an EVM chain — name, native currency, explorers, liveness-scored public RPCs. view='rpcs' returns only the ranked, eth_chainId-probed RPC list; view='wallet_config' returns a ready-to-submit EIP-3085 wallet_addEthereumChain object; view='search' finds chains by name or symbol; view='l2s' lists a parent chain's L2s. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Name/symbol fragment (view='search'). | |
| view | No | Which shape of chain data to return. | record |
| parent | No | Parent chain id for view='l2s'. | 1 |
| chain_id | No | Numeric chain id (required for record/rpcs/wallet_config). | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the paid nature with the exact two-step payment flow (call without x_payment for terms, sign, then call again with x_payment). It also documents behavioral details like liveness-scored RPCs and eth_chainId probing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but dense; every sentence adds a distinct piece of information. It is front-loaded with the core purpose and then systematically covers views and payment. Slightly long but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains what each view returns (ranked RPC list, EIP-3085 object, etc.) and the payment workflow. This is sufficient for an agent 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?
The schema covers 100% of parameters with good descriptions, but the description adds meaning by explaining the x_payment two-step protocol and the semantic differences between view values, which the schema only names with enum strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a 'Canonical record for an EVM chain' and enumerates the exact data types (name, native currency, explorers, RPCs). It differentiates from siblings like gas_price and spot_price by focusing on chain metadata, and further disambiguates internal views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear per-view usage guidance ('view='rpcs' returns...', 'view='search' finds...') and explicitly points to an alternative tool ('The free `pricing` tool lists every price at once'), telling the agent when not to pay per-call. It does not exhaustively contrast with all siblings, but the key alternative is covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an ENS name to an address, or an address to its forward-verified primary name — direction is detected from the input. view='profile' returns the full identity card (multichain addresses, text records, contenthash, avatar); view='avatar' dereferences the avatar to an image URL. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| keys | No | Comma-separated ENS text-record keys (view='text'). | |
| view | No | resolve = name↔address; profile/avatar/text need a name. | resolve |
| query | Yes | An ENS name (ends in .eth) or a 0x address. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It covers key behaviors: bidirectional resolution, direction detection, view-specific outputs (profile returns full identity card, avatar dereferences to image URL), and the payment requirement. It also reveals that the tool is paid and explains the two-call settlement mechanism. The only gaps are details like response format or error behavior, which are not critical for selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. The first sentence states the core purpose, the second covers view options, and the third explains the payment flow. Every sentence earns its place with no redundant or filler content. It is easy to scan and extract the key information quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple views, paid flow, bidirectional resolution), the description is remarkably complete. It explains the main behaviors, the payment process, and the view alternatives. It omits explicit mention of the 'text' view (only implying it via the keys parameter), but the schema fills that gap. The absence of an output schema is mitigated by the description's clarity about what each view returns.
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 describes all four parameters with examples and clear descriptions, achieving 100% coverage. The description does not add new parameter-level meaning beyond what's already in the schema; it repeats the x_payment flow and view options but does not introduce new semantics. Since the schema already does the heavy lifting, 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 opens with a precise statement of what the tool does: resolving an ENS name to an address or an address to its forward-verified primary name. It clearly identifies the resource (ENS names/addresses) and the verb (resolve), and further distinguishes sub-modes via the view parameter. This goes beyond a simple restatement and 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: direction is auto-detected, view options are described, and the paid two-step flow is explicitly explained (call without x_payment to get terms, then call with x_payment). It also names an alternative (the free `pricing` tool) for listing all prices. While it doesn't explicitly state when NOT to use this tool, the context is sufficiently clear for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the data you need in plain language (e.g. 'Apple risk factors 2023', 'is this token a honeypot', 'is this email deliverable', 'read this page'). Searches this server's datasets first, then the whole Professor Sausages catalog, and returns matching endpoints with method, URL, price, and how to call them. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What you're trying to find or do, in your own words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the search order (server datasets first, then catalog), the return payload (method, URL, price, how to call), and that it is free. It does not cover failure modes or pagination, but for a non-destructive search tool this is adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core instruction, and contains no redundant information. Every sentence adds value: what to describe, the search scope, and the output format/pricing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core behavior, return type, and scope well. It could mention what happens if no matches are found, but the tool is simple enough that this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter 'task' with a basic description, but the tool description enriches it significantly by explaining how to phrase requests ('in plain language') and providing varied examples. This adds meaning beyond the schema, despite the schema's 100% coverage.
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 function: it takes a natural language description of data needs, searches the server's datasets and the Professor Sausages catalog, and returns matching endpoints with method, URL, price, and call instructions. This distinguishes it from the sibling tools, which are specific data endpoints, by positioning it as a discovery meta-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?
The description provides clear context with multiple examples ('Apple risk factors 2023', 'is this token a honeypot') and implies use when you need to find the right data source, but it does not explicitly state when not to use it or name alternative tools. This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank every supported chain by all-in USD transaction cost — the 'where should I send this' routing decision, with the OP-stack L1 data fee included. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| gas | No | Optional gas limit override. | |
| speed | No | Fee tier to compare at. | standard |
| tx_type | No | Transaction shape to price on every chain. | transfer |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It transparently reveals the paid nature and the two-step payment protocol, and notes the inclusion of the OP-stack L1 data fee. However, it does not describe the output format or error behavior, which would be useful for 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and metric, followed by the essential payment flow details. It is concise, well-structured, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (paid flow, ranking, fee inclusion) and lack of output schema, the description covers the purpose, payment protocol, and alternative tool. It does not specify the ranking output format, but the context is sufficient for most agents to understand how to invoke and reason about the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has a detailed description. The tool description adds context for the payment flow but does not provide significant new meaning beyond what the schema already explains for gas, speed, tx_type, and x_payment. Thus 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 uses a specific verb 'Rank' with a clear resource ('every supported chain') and a precise metric (all-in USD transaction cost). It also distinguishes itself from siblings by positioning it as a routing decision and explicitly naming the 'pricing' tool as a free alternative, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (routing decisions) and contrasts it with the free 'pricing' tool that lists all prices at once. It also provides clear usage instructions for the paid flow: call without x_payment to receive terms, sign them, then call again with x_payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bid-ready EIP-1559 fees (slow/standard/fast maxFeePerGas + maxPriorityFeePerGas, tx-ready wei) for one chain, read live from public RPCs. Pass tx_type to get the USD cost of that specific transaction instead, including the OP-stack L1 data fee naive estimators miss. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| gas | No | Optional gas limit override when tx_type is set. | |
| chain | No | Which chain's gas market to read. | base |
| speed | No | Which fee tier to price the estimate at. | standard |
| tx_type | No | Optional: cost a specific transaction shape rather than returning raw fees. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses that data is read live from public RPCs, that the tool is paid via a two-step x402 flow, and that `tx_type` includes OP-stack L1 data fees. The payment mechanism is fully explained, ensuring the agent understands the cost and workflow before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each with a distinct purpose: core function, optional mode, payment workflow, and free alternative. No fluff or repetition. The most critical information is front-loaded in the first sentence, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explains both phases of the result: payment terms on the first call and data on the second. It covers live source, optional transaction costing, and the alternative `pricing` tool. For a tool with 5 optional parameters and no annotations, this is remarkably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context by explaining that `tx_type` changes the output from raw fees to USD transaction cost and detailing the two-step `x_payment` flow. It does not need to repeat schema descriptions, so a 4 is appropriate for the added clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it reads live EIP-1559 fees for a single chain, with specific fee tiers and optional transaction-cost mode. It distinguishes itself from the `pricing` tool, which lists all prices, and from `gas_compare`, which likely compares chains. The verb 'read' and resource 'fees' are clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: 'Pass tx_type to get the USD cost of that specific transaction instead' and 'The free `pricing` tool lists every price at once.' It also explains the payment flow, telling users to call without `x_payment` to receive terms, then call again with it. This fully orients an agent toward correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministic scam checklist with a verdict and evidence (spam flags, copymint collisions, holder concentration). Pass a collection contract to check the collection, or a wallet to check that wallet's whole scam exposure holding by holding. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Which chain to read (Ethereum mainnet today). | eth |
| wallet | No | Wallet address — checks scam exposure across its holdings instead. | |
| contract | No | Collection contract address to check. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It reveals determinism, the paid two-step flow (call without x_payment → receive terms → sign → call again), and the evidence shape. It does not cover edge cases like what happens if both contract and wallet are provided, but it gives substantial behavioral context for a paid tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences cover the purpose, two usage modes, payment workflow, and an alternative pricing tool. Each sentence earns its place; there is no fluff or repetition. The structure is front-loaded with the core purpose and then layers operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (4 params, payment flow, two modes, no output schema), yet the description covers all necessary aspects: what it returns (verdict/evidence), when to use each param, the payment protocol, and an alternative for pricing. It gives agents enough to decide and invoke correctly without requiring extra research.
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 is 3. The description adds minimal extra semantic value: it clarifies the either/or relationship between contract and wallet ('or a wallet to check...') and adds 'holding by holding' detail, but the schema already describes each parameter well. No need to compensate for missing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Deterministic scam checklist with a verdict and evidence' — a specific verb+resource statement that clearly identifies the tool's function. It further distinguishes itself from siblings by naming NFT-specific outputs (spam flags, copymint collisions, holder concentration) and by describing two operate modes (contract vs wallet). This is more than a generic 'check NFTs' statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is explicit: 'Pass a collection contract to check the collection, or a wallet to check that wallet's whole scam exposure holding by holding.' It also points to an alternative: 'The free `pricing` tool lists every price at once,' which tells the agent when NOT to use this tool for pricing. This meets the bar for explicit when/when-not/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every endpoint this server fronts, with its exact per-call USD price (x402, USDC on Base) and a one-line summary, read live from the route table. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that the tool is free, reads live data from the route table, and provides per-call prices and summaries. This gives key behavioral context (no cost, real-time source). It does not mention potential rate limits or response format, but for a simple listing tool this is sufficient.
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 exactly two sentences, with the first sentence packing all relevant information (what the tool returns, the currency, the source) and the second clarifying that it is free. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool, the description covers the essential context: what it lists, the price accuracy, the live source, and the free cost. No output schema exists, but the description adequately communicates what the agent will receive. There are no hidden prerequisites or side effects to disclose.
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 is empty (0 parameters), so there are no parameter semantics to clarify. Baselines for 0-param tools is 4. The description adds meaning by explaining the output (endpoints, prices, summaries), which is the only relevant semantic content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it lists every endpoint the server fronts with exact per-call USD pricing and a one-line summary. It differentiates itself from sibling tools by being a meta tool about pricing, not a functional data tool like gas_compare or ens_resolve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: one would call this to discover endpoint costs before making other calls. It says the prices are read live from the route table and are free, which suggests it is safe to use at any time. However, it does not explicitly say 'use this before calling other endpoints to check costs' or mention when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The suggestion box: ask for data we don't have (a pre-2015 filing, an uncovered ticker, an unsupported chain, a whole dataset). Requests feed the nightly ingestion queue — filings are usually available within ~24h. Include contact if you want to hear back. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| contact | No | Optional: URL/email/handle for follow-up | |
| use_case | No | Optional: what you're building | |
| description | Yes | What data you need, in your own words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior on its own. It does so by explaining that requests enter a nightly ingestion queue, filings are usually available within ~24h, and the service is free. This gives the agent insight into the async process and expectations, though it doesn't cover all side effects (e.g., confirmation or logging).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the metaphor 'The suggestion box' and immediately explains purpose, examples, process, latency, and cost. Every phrase adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple request/submission tool with no output schema, the description covers the purpose, workflow, expected delay, and optional feedback. It doesn't specify the confirmation response, but that's not critical for a queue-based request tool, and the overall context is sufficient for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters, so the baseline is 3. The description adds extra context by giving examples of valid 'description' content and mentioning the optional contact field for follow-up, but it doesn't introduce new parameter semantics beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'suggestion box' for requesting data the system lacks, with concrete examples (pre-2015 filing, uncovered ticker, unsupported chain). This distinguishes it from sibling data-retrieval tools, which serve existing data.
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 conveys when to use the tool: when you need data that isn't already available. It implicitly contrasts with sibling lookup tools and provides context (nightly queue, ~24h availability), but it does not explicitly name alternatives or state 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.
Live Chainlink on-chain spot price for an asset (latestRoundData, with round metadata). Pass to as well to cross-convert two assets via their USD feeds, with both legs reported. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional second asset — converts `asset` into it instead of quoting USD. | |
| asset | Yes | Asset symbol with a Chainlink feed (call /prices/feeds free to list them). | |
| chain | No | Which chain's oracle to read. | base |
| amount | No | Amount to convert (with `to`). | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
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 discloses the paid nature, the need for signed x402 payment, the use of Chainlink's latestRoundData, and that cross-conversion reports both legs. This goes beyond mere 'get price' and explains the operational behavior and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the core purpose first, then explaining optional conversion and the payment flow. Every sentence contributes unique, actionable information with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (paid, multi-step, cross-conversion) and lack of output schema or annotations, the description is remarkably complete. It covers the data source (Chainlink), the payment mechanism, the cross-conversion behavior, and directs to the alternative pricing tool. It sufficiently sets expectations for the return, mentioning 'round metadata' and 'both legs reported'.
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 is 3. The description adds value for `to` (cross-convert via USD feeds, both legs reported) and clarifies the x_payment flow, but the schema already explains these parameters in detail. The extra context pushes it slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Live Chainlink on-chain spot price for an asset (latestRoundData, with round metadata)'. It also distinguishes from the sibling 'pricing' tool by noting that the free `pricing` tool lists every price at once, making the purpose specific and non-duplicative.
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 explicit usage guidance, including the two-step payment process ('call without x_payment to receive this call's exact terms... then call again with x_payment') and directs to the free `pricing` tool for a bulk price list. It also references /prices/feeds for listing available feeds, clarifying when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Indicative UniswapV2 swap quote from live on-chain reserves: amount out, execution price, and price impact — what the trade will actually cost before you sign it. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Which chain to quote on. | base |
| amount | No | Amount of token_in to sell. | |
| token_in | Yes | Address of the token being sold. | |
| token_out | Yes | Address of the token being bought. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight. It discloses the paid nature, indicative/live-reserve sourcing, the x402/x_payment authentication flow, and that the quote reflects actual pre-sign cost. These behavioral traits go well beyond the structured schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the tool's purpose and outputs, and efficiently weaves in the payment flow and alternative tool without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description lists expected return values and explains both the free and paid invocation paths. Given the tool's complexity (5 params, multi-step payment), this is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described, so the baseline is 3. The description adds value by explaining the x_payment lifecycle (omit for terms, include to settle) and the meaning of the quote outputs, which enhances understanding beyond field names.
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 specifies the tool as an indicative UniswapV2 swap quote from live on-chain reserves, listing concrete outputs (amount out, execution price, price impact). It distinguishes itself from the sibling 'pricing' tool by being paid and providing exact per-trade terms rather than a list of all prices.
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?
Explicit when-to-use guidance is provided: 'call without x_payment to receive this call's exact terms, sign them, then call again with x_payment' and 'The free `pricing` tool lists every price at once.' This clearly differentiates from the free alternative and explains the two-step paid flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Heuristic token safety check: follows the proxy and scans the bytecode that actually runs, plus ownership and transfer restrictions. Returns a verdict with per-rule evidence. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Which chain the token contract is on. | base |
| address | Yes | Token contract address. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the heuristic nature, proxy-following behavior, and that it returns a verdict with per-rule evidence. It also transparently explains the payment requirement and two-step call pattern, providing strong behavioral context beyond a simple 'checks token safety' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three short sentences. It front-loads the primary purpose, then explains the payment flow and pricing alternative without wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, output format (verdict with per-rule evidence), the payment mechanism, and an alternative tool. It lacks explicit mention of error cases or edge cases, but for a heuristic check tool with good parameter docs, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The tool description reiterates the payment flow but does not add any new parameter-level meaning beyond what is already in the schema's x_payment description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a heuristic token safety check that follows proxies and scans runtime bytecode, plus ownership and transfer restrictions. It distinguishes itself from sibling tools like nft_scam_check by focusing on rug-pull/honeypot detection and even points to the pricing tool for price-related needs.
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 explicit usage instructions for the paid payment flow (call without x_payment to get terms, sign, then call again with x_payment) and mentions the free pricing tool as an alternative for pricing. It doesn't explicitly exclude other sibling tools but gives clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
address_screenchain_infoens_resolvefind_datagas_comparegas_pricenft_scam_checkpricingrequest_dataspot_priceswap_quotetoken_safetyClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool has a clear, distinct purpose: address screening, chain info, ENS resolution, data discovery, gas routing, gas pricing, NFT scam checking, pricing metadata, data requests, spot prices, swap quotes, and token safety. Although gas_compare and gas_price both involve gas, one ranks chains while the other gives fees for a single chain; token_safety and nft_scam_check target different asset types. No two tools are likely to be confused.
Names are all lowercase snake_case but follow no single convention. Some are verb-first (find_data, request_data, swap_quote), some noun-first with a verb (address_screen, ens_resolve, gas_compare), and several are noun-noun compounds (chain_info, gas_price, spot_price, token_safety). This mixed pattern makes the naming feel inconsistent, even though each name is readable.
With 12 tools, the server sits comfortably in the well-scoped range for a blockchain data/utility provider. Each tool addresses a distinct need, and the count is not excessive for the breadth of on-chain operations covered. Every tool appears to earn its place without redundancy.
The tool surface covers a broad set of on-chain needs: screening (address, token, NFT), pricing (spot, swap, gas), identity (ENS), chain metadata, and meta-tools for discovery and requests. Minor gaps exist, such as no direct transaction/block inspection or portfolio-level functions, but these are not core to the server's apparent purpose and agents can work around them using find_data to locate additional endpoints.