anchor-x402-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.1
Disambiguation5/5
Each tool targets a unique operation: anchor/attest, decode calldata/decode tx, wallet intel, datetime parsing, name resolution, AML screening, token price. No overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., anchor_hash, decode_calldata, screen_wallet), making predictions easy.
Tool Count5/5
9 tools is well-scoped for a blockchain utility server that covers anchoring, attestation, decoding, wallet intelligence, and common lookups.
Completeness4/5
Covers core functionalities, but lacks a direct verify_anchor or verify_attestation tool; however, built-in proof URLs partially mitigate this gap.
Average 4.3/5 across 9 of 9 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on June 24, 2026
- 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.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description provides some behavioral info: 'Mined txs cached in-process' and pricing ($0.001). However, it does not disclose authentication requirements, rate limits, or error conditions, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action. No redundant information. However, could be slightly more structured by separating output details from pricing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and no output schema, the description covers inputs, outputs (per chain), use cases, caching, and pricing. It is sufficiently 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only tx_hash described). The tool description reiterates that chain is from the given enum list and tx_hash is the hash, adding minimal value beyond schema. It does not explain what the returned fields mean in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it decodes a mainnet transaction by hash, specifying the input requirements (chain and hash) and output fields per chain. Differentiates from sibling tools like decode_calldata which only decode calldata, not full transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples of use cases (tx inspection, audit, agent UX) but does not explicitly state when not to use it or mention alternatives. Lacks guidance on when to prefer this over decode_calldata for calldata-only needs.
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 carries the full burden. It discloses the output format (grade, marginalia, summary) and cost but omits behavioral traits like data persistence, idempotency, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core function (grade with marginalia and summary) and then adding usage and cost. Every sentence provides necessary information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately explains the output and input constraints (6000 chars via schema). It covers the essential aspects for an agent to decide if and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one required parameter 'target'. The description adds value beyond the schema by calling the input 'universal' and listing examples (code, pitch deck, etc.), which helps the agent understand acceptable inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool grades by providing a letter grade (A+ to F) with marginalia and a summary, and clarifies the universal input type. It distinguishes from siblings like 'roast' by focusing on academic-style grading with specific output components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states use cases (sharp feedback, prompt engineering eval, pre-investment screen) and cost ($0.01 USDC). While it doesn't mention when not to use or name alternatives, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses cost ($0.005 USDC) and the data sources (8-10 parallel free public sources) but lacks details on rate limits, authentication needs, error handling, or data freshness. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Front-loaded with the core value proposition: 'Unified wallet intelligence bundle. ONE call returns...' Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-chain, multiple data points), the description covers the major return elements. Missing details like error cases or data update frequency, but overall sufficient for an agent to understand what it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'wallet' with schema description 'EVM 0x… address (40 hex) or Solana base58 pubkey.' Schema coverage is 100%, making the description sufficient. No additional insight beyond the schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Unified wallet intelligence bundle' returning balances on Base, Ethereum, Solana, USDC across chains, transaction count, ENS/SNS reverse lookup, and sanctions verdict. It distinguishes from sibling tools like screen_wallet by advertising aggregated data from 8–10 sources in one call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases: 'KYB pre-flight, counterparty research, fraud detection'. Does not explicitly state when not to use or compare to alternatives, but the context is clear enough 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the cost ($0.005 USDC), the dual-chain anchoring, and that it returns transaction hashes and URLs. It states 'pure infrastructure — no opinions about content', but does not discuss permanence, reversibility, or potential errors. This is adequate but not highly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the core purpose, then details returns, use cases, and cost. It is dense but not overly long. Minor redundancy ('Pure infrastructure') could be trimmed, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description explains the return values (both transaction hashes plus block-explorer URLs). It covers intended use cases, cost, and behavior. It lacks details about prerequisites (e.g., needing USDC balance) or error scenarios, but for a simple tool with three parameters it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 3 parameters with full descriptions. The description adds meaning: it clarifies that 'data' is canonicalized and SHA-256'd by the server, and that 'note' is optional and off-chain. This goes beyond the schema, which only describes the 'hash' parameter's format and mutual exclusivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: anchoring a 32-byte hash to both Base mainnet and Solana mainnet in a single call. It specifies the verb 'anchor' and the resource (hash), and distinguishes from siblings like 'attest_decision' which likely handles decision attestations rather than generic hash anchoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (DAO vote receipts, AI decision attestations, etc.), giving clear context for when to use the tool. However, it does not explicitly mention when not to use alternatives or compare to sibling tools like 'attest_decision'.
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 discloses behavior: LLM provides answer with reason, anchors a SHA256 hash to Base and Solana, and costs $0.05 USDC. It sets proper expectations about verifiability and cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single focused paragraph covering key points. It is concise but could be broken into bullet points for easier parsing. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers purpose, behavior, cost, and use cases. It lacks explicit return format specification, but the context is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes the 'question' parameter as a yes/no question. The description adds context about the answer format (one-sentence reason) but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool is a yes/no oracle that returns an answer (YES/NO/MAYBE) with a reason and anchors it to two blockchains for verifiability. It distinguishes itself from sibling tools like 'attest_decision' or 'grade' by its blockchain anchoring and specific use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases: prediction-market commits, conditional contracts, time-stamped opinions, settling bets. This helps the agent decide when to use this tool over siblings, though it does not explicitly 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.
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 discloses cost ($0.001 USDC) and explains the output structure (ISO 8601, unix epoch, components, confidence). It does not mention error handling or limits, but overall provides good behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes examples, output list, and cost info. It is concise but somewhat dense; slight improvement could come from breaking into bullet points or shorter sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains the return format (ISO 8601, unix epoch, components, confidence). It also adds context on pricing. However, it does not cover error cases or rate limits, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to repeat parameter definitions. It adds value by providing example inputs ('tomorrow at noon') and stating the default behavior for optional parameters, going beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Parse') and resource ('freeform datetime string') and lists detailed output components. It clearly distinguishes itself from siblings like anchor_hash or decode_calldata which serve entirely different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear usage hint ('Saves agent LLM tokens on date parsing') implying efficiency is a reason to use this tool. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses the tone ('clever, not mean-spirited') and output structure, as well as cost ($0.05 USDC). However, it does not mention side effects, response time, or that it uses an LLM, which is acceptable for a simple generation tool 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences covering purpose, examples, output, tone, usage, and cost. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given 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 format (3-5 paragraph roast + neutral summary). For a generation tool with minimal parameters, this covers all necessary information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'target' is fully described in the schema (100% coverage). The description adds value by expanding on what constitutes a target (anything, including examples) and specifying the character limit (8000 chars), going beyond the schema's brief description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a witty, observational roast with specific examples of targets (wallet address, tweet, etc.) and mentions the output format (3-5 paragraph roast + neutral summary). This distinguishes it from sibling tools like 'grade' or 'tldr'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use for entertainment, demo content, social,' providing clear context for when to use. It does not explicitly mention when not to use or list alternatives, but the unique nature of this tool among siblings makes this 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?
No annotations provided, but description fully discloses the verification process, domain separation, dual-chain anchoring, return values, and cost ($0.010 USDC), meeting the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover the core function and use cases, with cost appended. Every sentence earns its place; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return value (signer + proof URLs) and includes cost. Lacks error handling or prerequisites, but sufficient for a straightforward tool with clear inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). Description adds no extra parameter details beyond the overall process, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool verifies a wallet signature and anchors a Merkle root on two chains, with specific verbs and resources. No confusion with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases (autonomous trade approvals, AI-assisted contract decisions, etc.) and provides context. Lacks explicit 'when not to use', but sufficient for the intended purpose.
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 discloses behavioral traits: resolves 4-byte selector via openchain.xyz, ABI-decodes args, provides cost ($0.001 USDC), and specifies error for solana. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with main purpose, logically structured with key details (behavior, use cases, constraints) in minimal sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides sufficient context for a tool with no output schema: purpose, external resolution, cost, constraints. Lacks details on failure cases (e.g., invalid calldata, missing signature), but coverage is adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100% coverage). Description adds minor value by reinforcing chain constraint and calldata requirements, but largely repeats schema descriptions. No significant extra semantic insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'decode' and the resource 'raw EVM calldata', listing specific outputs (function name, signature, typed parameter values). It distinguishes from siblings like decode_tx by specifying EVM-only and calldata-level decode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases (tx inspection before signing, mempool analysis, debug) and constraints (EVM-only, solana returns 400). However, no direct mention of alternatives among sibling tools.
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 provided, so description carries full burden. Discloses return fields (sanctions match, OFAC programs, chain, risk verdict) and cost. No mention of rate limits or error handling, but key behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, front-loaded with purpose. Every sentence adds value (purpose, inputs, outputs, use cases, cost). No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description adequately explains inputs, outputs, use cases, and cost. Could elaborate on error cases or chain detection, but overall sufficient for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description. Description reinforces accepted address formats (EVM hex or Solana base58) and adds context about chain inference. Goes beyond schema by specifying output details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Sanctions + AML screening for any EVM or Solana wallet address', using specific verb (screening) and resource. Distinguishes from siblings like intel_wallet or decode_tx by focusing on sanctions compliance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases: AML pre-flight checks, KYC onboarding, vendor diligence, etc. Does not mention when not to use or alternatives, but the guidance is clear and comprehensive.
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 exist, so the description bears full weight. It discloses fetching up to 500KB, stripping HTML via BeautifulSoup, and a cost of $0.01 USDC. No destructive behavior is implied. It could mention auth or rate limits, but the transparency is good for a simple 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences each adding value: main action, technical detail, usage and constraints, and cost. Front-loaded with purpose, no wasted words. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but the description covers purpose, behavior, constraints, use cases, and cost. It doesn't specify error handling (e.g., if both parameters provided) or output format details beyond '3-5 bullets,' but given no output schema, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter described. The description adds the mutual exclusivity rule 'Exactly one of text or url' and context for the URL parameter regarding size limits. This adds meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool summarizes a URL or pasted text into 3-5 concise bullets, with specific verb and resource. It includes details like fetching up to 500KB and stripping HTML, and is distinct from siblings like 'roast' or 'decode_tx'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'research distillation, link-rot insurance, agent reading lists.' It also states the mutual exclusivity constraint 'Exactly one of text or url.' However, it does not name alternatives or specify when not to use the tool, though no direct alternative exists among siblings.
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 fully covers behavioral traits: it mentions server-side caching (1 hour) and cost ($0.001 USDC). It also notes that only two registries are currently supported, setting correct 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences, each serving a purpose: stating the function, giving usage examples, and providing operational details (registries, caching, cost). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 is complete. It explains purpose, input format, supported services, caching behavior, and cost, covering all relevant aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the only parameter (name) with 100% description coverage. The description adds value by providing example values ('vitalik.eth', 'bonfida.sol') and clarifying the format, which goes beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves human-readable names across blockchains, specifying supported registries (ENS, SNS) and giving examples ('vitalik.eth', 'bonfida.sol'). It distinguishes from siblings like anchor_hash or decode_calldata, which are unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool (cross-chain name resolution) but does not explicitly state when not to use it or provide alternatives. However, the context is clear enough for an AI agent to decide appropriately.
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?
No annotations provided, but description fully covers behavior: CoinGecko-backed, cached 60s, cost $0.001 USDC, and returns USD price, 24h change, market cap, and timestamp. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences packed with all necessary information: purpose, parameters, source, caching, cost, and return fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite missing output schema, description compensates by listing return fields (price, change %, market cap, timestamp). Covers input options, source, caching, and cost. Fully sufficient for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds marginal value. It reiterates mutual exclusivity (already in schema) and provides example values, enhancing usability but not essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns USD spot price for major tokens, specifying two input options (symbol or chain+contract). Distinct from siblings which deal with hashes, attestations, decoding, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells agent to pass either 'symbol' OR 'chain+contract', with examples. Does not explicitly exclude alternatives, but siblings are unrelated so usage is 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?
Discloses output format, input type, and cost ($0.01 USDC). No annotations exist, so description carries burden. Could mention data sources or rate limits, but remains sufficient for a simple 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: output, input scope, use cases and cost. Front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool (1 param, no output schema), description covers purpose, input, output, cost, and use cases comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes 'target' with max chars. Description adds examples (wallet, tweet, project) and emphasizes universality, enriching beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reads aura of any target and returns specific outputs (color, tier, score, description). It distinguishes from siblings by its unique function (aura reading) and universal input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'viral / shareable content, brand vibes, social'. Does not mention when not to use or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![anchor-x402-mcp MCP server](https://glama.ai/mcp/servers/hypeprinter007-stack/anchor-x402-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hypeprinter007-stack/anchor-x402-mcp)

Score Badge

Copy to your README.md:

[![anchor-x402-mcp MCP server](https://glama.ai/mcp/servers/hypeprinter007-stack/anchor-x402-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hypeprinter007-stack/anchor-x402-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hypeprinter007-stack/anchor-x402-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server