agent402-mcp

Server Quality Checklist

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

Latest release: v0.12.2
Disambiguation4/5
Most tools have distinct purposes, but wallet_balances and wallet_balance overlap slightly (both check balances across chains). Also extract and render serve similar content extraction purposes, though the JS execution distinction helps. Overall, the set is mostly unambiguous.
Naming Consistency5/5
All tool names use consistent snake_case with clear verb_noun patterns (e.g., memory_write, wallet_balances, route_and_execute). The naming is predictable and easy to parse for an agent.
Tool Count4/5
At 23 tools, the count is slightly above the typical sweet spot but still justified given the breadth of functionality offered (web, memory, wallet, meta-tools). It avoids being overwhelming.
Completeness4/5
The tool surface covers web operations, memory, wallet queries, and meta-tool discovery. Minor gaps exist (e.g., no tool for sending transactions), but the inclusion of route_and_execute and search_tools mitigates this by allowing access to external tools.
Average 4.1/5 across 23 of 23 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 51 of 53 community issues answered or closed in the last 6 months
- 1674 commits in the last 12 weeks
- Last stable release on July 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
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.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/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 the cost and wallet requirement, and notes supported record types. However, it does not mention behavior for invalid domains, rate limits, or response structure, leaving moderate gaps.
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 with no wasted words. It front-loads the key purpose and cost, then lists supported record types. Every sentence is essential.
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 only two parameters and no output schema, the description is largely complete. It covers the operation, inputs, supported types, and cost. However, it lacks a description of return values or error handling, which would be expected for a 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% with clear parameter descriptions. The description adds supported record types and pricing but does not provide additional semantic meaning beyond what the schema already conveys, earning a baseline score.
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 performs DNS lookups for a domain and lists supported record types (A, AAAA, MX, TXT, NS, CNAME). It distinguishes from sibling tools like whois (WHOIS lookups) and http_check (HTTP checks) by specifying a distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., whois for registration info). The description mentions a wallet requirement and cost, but does not specify prerequisites or context for use.
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?
Discloses cost ($0.015/call) and wallet requirement, and notes the use of headless Chromium. However, lacks details on failure modes (e.g., loading errors, timeouts) or rate limits, which are important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: cost tag, purpose, result type, and parameter summary in a single sentence with 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?
For a simple tool with two parameters and no output schema, the description adequately covers cost, usage constraints (public URL), and result type (PNG). Could mention error handling or default behavior for fullPage=false, but sufficient.
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 the description repeats the parameter usage ('Query params: ?url=…&fullPage=true'). No additional semantic meaning beyond 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 'Screenshot any public URL' using headless Chromium, specifying the action, target, and implementation. It contrasts with sibling tools like 'pdf' and 'render' by emphasizing PNG output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when not to use this tool or alternatives among siblings. Only mentions 'any public URL' as a constraint, but does not explain when to prefer it over 'pdf' or 'render'.
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?
Discloses cost ($0.003/call) and wallet requirement, but no annotations are provided. Does not mention if the operation is read-only or potential side effects, though 'inspect' implies read-only.
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?
Single sentence effectively communicates purpose, cost, and output details with no superfluous 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?
With no output schema, description adequately lists output fields. Includes cost and wallet info. Could mention error handling or response format but sufficient for a simple 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% (one required parameter with description 'Hostname (port 443)'). Description adds no additional meaning to the parameter beyond listing output fields.
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 inspects TLS certificates of public hosts and lists specific certificate fields (subject, issuer, validity, etc.), distinguishing it from sibling tools like whois or dns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs. alternatives. Only states what it does, but does not mention scenarios where other tools (e.g., whois, http_check) would be more appropriate.
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 cost per call, the prerequisite of a wallet, and that balances are scaled by decimals. It does not mention rate limits, authentication, idempotency, or data freshness, leaving gaps for a potentially complex call.
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: one brief sentence with a bracketed note for cost/requirement. It front-loads the cost and prerequisite, then clearly states the action and output. Every part is necessary and well-structured with 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?
Given no output schema, the description adequately explains return values (scaled balances, symbol, contract) and suggests use cases (UI, portfolio tool). It covers supported networks. However, it does not mention error handling, pagination for many tokens, or potential timeouts, which could be relevant for a tool with network-specific behavior.
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?
The schema has 100% coverage, providing clear descriptions for both parameters. The description adds no new information beyond the schema; it only reiterates the network options and address format already present in the schema. Thus, the description adds little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action: look up native coin balance and all ERC-20 holdings for a wallet address on multiple networks. It states the returned data (scaled balances, symbol, contract). However, it does not differentiate from the sibling tool 'wallet_balances', which could cause confusion.
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?
The description includes a prerequisite ('wallet required') and a cost note, implying when to use. It also suggests the output is suitable for UI or portfolio tools. However, it does not explicitly state when not to use or mention alternatives like 'wallet_transactions'.
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 provided, and the description does not disclose behavioral traits such as side effects, read-only nature, or any constraints. For a simple informational tool, some indication that it is safe and non-destructive would help.
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?
One sentence clearly explaining the tool's purpose with no redundant or irrelevant information. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose but does not specify the output format or any additional context about what 'what that unlocks' means. With no output schema, more detail on return type would improve completeness.
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?
No parameters exist, so the schema provides full coverage. The description adds no parameter-level detail, which is acceptable given zero parameters. Baseline for 0 params is 4.
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 explains how the server pays for calls (USDC wallet vs proof-of-work) and what that unlocks, specifying the resource and scope. This distinguishes it from sibling tools like wallet_balances or wallet_transactions, which focus on balance or transaction details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding payment methods, but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not guidance or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions cost and wallet requirement, but does not describe error behavior, rate limits, or what happens if the domain is not found. The RDAP protocol is mentioned, but response format or potential failures are omitted.
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 a single, front-loaded sentence that includes cost, protocol, and returned data without unnecessary words. Every element serves a purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 adequately lists the returned fields and mentions the protocol. However, it lacks details on error scenarios or the structure of the response (e.g., JSON format). For a simple lookup tool, this is acceptable but not fully 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 single parameter 'domain' has 100% schema coverage, but the description adds value by clarifying it must be a registrable domain with an example (example.com). This goes beyond the schema's basic 'Domain name' 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 that the tool provides domain registration data via RDAP, listing specific data items like registrar, creation/expiry dates, status, and nameservers. This distinguishes it from sibling tools like dns, tls_cert, and http_check, which handle different aspects.
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?
The description includes cost and wallet requirement but does not provide explicit guidance on when to use this tool versus alternatives like dns or search. Usage context is implied by the focus on registration data, but no when-not or alternative recommendations are given.
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?
The description discloses cost and wallet requirement, and lists the types of metadata returned. However, it does not cover failure behavior, rate limits, or caching policies. With no annotations, more depth is expected.
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 (15 words) and front-loaded with cost and wallet requirement. Every word adds value, with 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 output schema, the description adequately explains what the tool returns (list of metadata fields). It also covers the preconditions (cost, wallet). Minor omission: the response format (e.g., JSON) is not explicitly stated, but it's implied.
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 baseline is 3. The description adds no additional meaning to the 'url' parameter beyond what the schema already provides ('Public http(s) URL').
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 fetches page metadata for a URL and lists specific items (title, description, OpenGraph, Twitter cards, canonical URL, favicon), effectively distinguishing it from sibling tools like http_check or screenshot.
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?
The description mentions cost and wallet requirement, which are prerequisites, but provides no explicit guidance on when to use this tool over alternatives, such as search or extract. Usage context is implied but not elaborated.
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 cost per call, wallet requirement, output structure, and a size limit (up to 20MB). With no annotations, this provides essential behavioral context, though error handling and redirect behavior are omitted.
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 concise sentences; first sentence front-loads the core action ('Fetch a PDF and extract text') without extraneous words. Every sentence provides value.
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 single-parameter tool with no output schema, the description covers core behavior, output, and limits. Minor gaps like error handling exist, but it is adequate for basic 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 contains full description of the 'url' parameter and coverage is 100%. The main description adds no extra detail about the parameter beyond the schema, meeting the baseline.
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 fetches a PDF and extracts text, with specific outputs (page count, document info, full text). It distinguishes from siblings like 'screenshot' or 'extract' by focusing exclusively on PDFs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'extract' or 'screenshot'. The cost note implies a constraint but doesn't help the agent decide between 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?
With no annotations provided, the description carries full burden. It discloses the cost ($0.002/call), wallet requirement, ranking method (cosine similarity), and return format (top-k with scores). However, it does not detail error handling, empty results, or authorization specifics beyond owner requiring a grant.
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 three sentences long, front-loaded with cost and requirement, then core functionality and outcome. Every sentence is essential, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description explains the tool's purpose and parameters adequately. However, it does not detail the return structure beyond 'top-k matches with scores', missing specifics like whether it returns an array or object, what fields each match contains, or how scores are presented.
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 description coverage is 100%, so the schema already documents all parameters. The description adds context by explaining query as natural-language and k as top matches count, but does not provide additional meaning beyond what the schema states. Baseline 3 is appropriate.
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 recalls remembered text by similarity to a query using cosine similarity, and distinguishes itself from exact key retrieval. It also identifies itself as the retrieval half of wallet-scoped semantic memory, distinguishing it from sibling tools like memory_write and memory_read.
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?
The description implies usage for similarity search rather than exact key, but does not explicitly state when to use this tool versus alternatives like memory_read (likely exact key) or memory_remember (write). It lacks explicit when-to-use or when-not-to-use guidance.
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 cost ($0.010/call) and wallet requirement, which is important for agent decision-making. Also flags untrusted content. No annotations provided, so description carries burden; it covers key behavioral aspects but omits error handling or rate limits.
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 with additional cost and trust notes. Information is front-loaded (cost, purpose, output, trust). No unnecessary 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?
Given simple tool with one parameter, no output schema, no annotations, the description covers cost, output fields, and trust. Lacks details on error cases (e.g., non-URL, non-article) but sufficient 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?
Only one parameter (url) with schema description 'Public http(s) URL to extract'. Schema coverage is 100%. Description adds minor context ('any public URL') but does not significantly enhance understanding beyond 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?
Clearly states the action 'extract main article content' from 'any public URL' and output format 'clean markdown'. Returns specific fields (title, byline, etc.). Differentiates from sibling tools like http_check, tls_cert, whois, etc. which serve 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Implies usage through description but does not mention alternatives or exclusions. The trust note ('Marked untrustedContent') provides context but not comparison with 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 provided, the description carries the full burden. It discloses the tool returns status code, latency, final URL, and response headers, and mentions cost and wallet requirement. However, it does not detail error handling or potential failures like timeouts, though the scope is simple enough that this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence followed by a useful tagline. Every part 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.
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 2 parameters and no output schema, the description covers purpose, cost, usage context, and return components. It is fairly complete, though a note about error behavior or timeout limits would make it more robust.
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 description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it explains the URL parameter implicitly ('any public URL') but does not elaborate on the method parameter beyond what's in 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 checks any public URL for status code, latency, final URL after redirects, and response headers. It uses a specific verb and resource, and distinguishes itself from siblings like tls_cert and whois by focusing on HTTP metadata.
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?
The description calls it 'the uptime primitive for agent monitors,' implying use for monitoring, but does not explicitly state when to use this versus alternatives or when not to use it. The tagline provides context but lacks explicit guidance.
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?
Discloses key behaviors like payment from wallet, untrusted content relay, and fee tiers, but lacks details on failure modes or timeouts.
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 dense and informative, but could be more structured. It front-loads the main concept well.
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 input and behavior adequately for a routing tool, though return format is only briefly mentioned (untrustedContent).
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%, and the description adds useful context like maxUsd tier and plain-language task interpretation, going beyond schema 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 clearly states the tool routes plain-language tasks to external x402 sellers, distinguishing it from sibling tools that are specific utilities.
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 clear context for use (routing to any external seller) and prerequisites (funded wallet, AGENT_KEY), but does not explicitly mention 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 full burden. It discloses cost, wallet requirement, default namespace, and access grant requirement. Missing details like behavior on missing key or unauthorized access, but overall adequately transparent for a simple read operation.
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, front-loaded with cost and wallet requirement, each sentence adds distinct value. No redundancy or unnecessary 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?
No output schema, but description vaguely indicates return values ('returns the stored value' or 'list keys'). Adequate for a simple key-value read tool, though missing details on error responses or exact format.
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%, but description adds significant value by explaining syntax (?key=...), default behavior, and access grant requirement. This goes beyond the schema descriptions, which are brief.
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 reads from a wallet-scoped namespace, returns stored values for a given key or lists keys. It distinguishes from siblings like memory_write (write) and memory_recall (likely semantic search) by specifying key-value read semantics.
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?
The description explains how to read your own namespace or another with the owner parameter, but does not provide explicit when-to-use or when-not-to-use guidance relative to siblings like memory_recall. Usage is implied but not explicitly contrasted.
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 the burden. It discloses cost ($0.003/call), wallet requirement, and the fact that the index is per-wallet and not hostable in-session. It does not cover rate limits, data persistence, or error cases, but it provides key behavioral context for a store 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?
Two sentences that are front-loaded with purpose, cost, and pairing hint. No unnecessary words, clear structure.
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 store tool with complete schema and no output schema, the description covers purpose, cost, identifier, and paired tool. Missing details about error cases or data limitations are minor given schema constraints.
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 has 100% coverage for all 3 parameters. Description does not add additional meaning beyond what schema provides; it only mentions storing text and returning an ID, without elaborating on meta or owner parameters. Baseline 3 is appropriate.
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 stores text for later similarity recall, uses a per-wallet semantic index, returns an ID, and pairs with memory_recall for retrieval. It distinguishes from sibling tools like memory_recall (retrieve vs store) and memory_read/write.
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 tells when to use it (store text for semantic recall) and explicitly pairs it with memory_recall for retrieval. However, it does not explicitly mention when not to use other sibling tools like memory_write or memory_read, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses cost, wallet requirement, headless browser with JS execution, markdown extraction, and a security note. It does not cover potential error behaviors or timeouts, but major 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading cost and wallet requirement, then the action, use case, and security note. No unnecessary 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?
For a single-parameter tool with no output schema, the description is fairly complete: it explains what the tool does, when to use it, and a security concern. It lacks details on return format (though markdown is mentioned) and error handling.
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 description coverage is 100%, baseline 3. The description adds context (cost, wallet) but does not add specific semantics to the url parameter beyond what the schema already states ('Public http(s) URL').
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 renders a page in a real headless Chromium browser with JavaScript execution and extracts main content as markdown. It distinguishes from plain fetching by specifying use for SPAs and JS-heavy sites.
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 recommends this tool for SPAs and JS-heavy sites where plain fetching returns empty shells, providing clear context. It does not exhaustively list when not to use, but it gives a strong usage hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses cost, free proof-of-work option, algorithm list, return format, and input size limit (100KB). This is good behavioral transparency for a simple hashing 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?
The description is two sentences, front-loaded with cost, then function and details. Every sentence provides value without redundancy or fluff.
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 no output schema, the description explains return format (hex and base64). It covers pricing, algorithm selection, and input constraints. For a simple hash tool, this is complete and requires no additional context.
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%, baseline 3. The description adds meaning by listing algorithm options (sha256 as default) and clarifying the text parameter's max size (100KB), going beyond the schema enum and 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 it computes cryptographic hashes of text strings, lists specific algorithms (sha256, sha512, sha1, md5), and mentions return formats (hex and base64). This distinguishes it from sibling tools like http_check or whois.
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?
The description mentions pricing but does not provide explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it. Usage is implied for hashing text, but no exclusions or comparison to siblings are given.
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 the scope of the catalog, pricing models (pay-per-call, free via proof-of-work), and the LLM gateway. Without annotations, it adequately covers behavioral traits.
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 dense but all information is relevant. Could be slightly more structured, but no wasted 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 explains what is returned and how to proceed. Sufficient for a search 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 covers both parameters fully, and the description adds concrete query examples that 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?
The description clearly states it searches the Agent402 catalog for tools and workflow templates, returning matches with pricing and schema. It distinguishes itself from sibling tools by being the search entry point.
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 query examples and explains that found tools are callable via call_tool. Does not explicitly state when not to use it, but the context of search 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?
With no annotations, the description carries the full burden. It discloses the payment mechanism (x402 or proof-of-work) and costs for certain tools, which is transparent. It does not discuss idempotency or side effects, but those depend on the called 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?
Two sentences, front-loaded with purpose, then concise payment details. 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?
For a generic caller with two parameters and no output schema, the description covers usage pattern and payment. It is fairly complete, though it could mention that the return value is the called tool's output.
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%. The description adds meaning by explaining that slug is from search_tools and gives an example ('unit-convert'), and that params match the inputSchema. This goes 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 'Call any Agent402 tool by slug', which is specific and distinguishes it from sibling tools like search_tools that provide slugs and input schemas.
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 tells the agent to find slugs with search_tools, implying when to use this tool. However, it does not explicitly state when not to use it or compare with other sibling tools like route_and_execute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses default behavior (top 10, sort by USDC, exclude own wallet) and that the data is derived from on-chain USDC transfers and is free. It lacks details on rate limits or data freshness beyond 'last ~24h', but overall provides sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by usefulness and defaults. Every sentence adds value with no redundancy or 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?
Given no output schema and no annotations, the description covers the tool's purpose, usage, and defaults adequately. It could be improved by briefly noting the output format (e.g., list of sellers with metrics), but the current description is sufficient for a simple listing 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?
The schema covers all parameters (100% coverage), so baseline is 3. The description adds value by explaining defaults (limit default 10, max 50) and the 'include' parameter's effect (exclude own wallet by default), going beyond the schema 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 clearly states the tool lists x402 sellers earning most USDC or serving most calls on Base in the last ~24h, with specific verb 'list' and resource 'x402 sellers'. It distinguishes itself from sibling tools by focusing on a niche on-chain economy.
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 explains it is useful for discovering the live x402 economy and notes it is free to call with no payment or proof-of-work required. However, it does not explicitly exclude misuse cases or describe when to prefer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses pricing ($0.002/call), requirement of a wallet address, data source (Coinbase indexed data API), supported networks, and that symbols/decimals are populated for whitelisted tokens (USDC always included). Rate limits and failure modes are not mentioned, but for a read-only 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a brief network list and note on whitelisted tokens. It is front-loaded with the most critical info (cost, requirement, capability). Every sentence adds value, with no redundancy or 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?
Given no output schema, the description explains that all token balances are returned and mentions that symbols/decimals are populated for whitelisted tokens. This gives a solid idea of the output structure. It could mention whether there is a limit on the number of tokens or pagination, but overall it is complete enough for an AI agent.
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 both parameters described. The description adds meaning beyond the schema: it explains that 'address' should be EVM 0x… or Solana base58 matching network, and for 'network' it lists all options and notes base as default. This provides context the schema alone does not.
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 retrieves all token balances for any address in one call, covering ERC-20 + native on EVM and SPL on Solana. It distinguishes itself from per-token contract calls and other tools like 'wallet_balance' (singular). The verb 'get' is implicit, and the resource is explicitly 'all token balances'.
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 when to use this tool: when you need all token balances in one call, avoiding per-token contract calls and RPC wrangling. It lists supported networks. However, it does not explicitly mention when not to use it or name alternatives, such as 'wallet_balance' for single token queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: cost ($0.002/call), requirement (wallet required), merging, sorting, cap per direction, output fields (block, tx hash, counterparty, asset, decimal value). This exceeds typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with cost and requirement. Every sentence adds useful information: token types, sorting, output fields, and limitations. 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?
Given no output schema, the description explains output structure. It covers capability and limitations (cap, fromBlock). Lacks error handling or rate limits, but is sufficient for a data retrieval 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 parameters are already well-described. The description adds minor context (cap per direction) but mostly restates schema defaults. Baseline 3 is appropriate as it does not significantly enhance parameter understanding.
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 explicitly states it returns asset transfers (incoming+outgoing) for a wallet, covering multiple token types, merged and sorted. It clearly distinguishes from balanced-focused sibling tools like wallet_balances and wallet_balance.
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 context on when to use (get recent transfers) and mentions limitations like cap of 100 per direction and fromBlock for deeper history. It does not explicitly state when not to use or name alternatives, but the sibling set implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses cost ($0.002/call), authentication method (x402 payment), TTL expiration, delete functionality, cross-namespace grants, and size limits (64KB). It does not specify the return value on success, but the information is substantial.
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 compact (two sentences) and front-loaded with cost and authentication. Every sentence adds value, and the body format is clearly outlined without unnecessary detail.
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 absence of an output schema and the presence of sibling tools, the description covers the key aspects: write/delete semantics, TTL, cross-namespace ownership, and limits. It lacks information about the response (e.g., success/failure), but this is a minor gap for a write tool.
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?
Although schema coverage is 100%, the description adds significant meaning by explaining the body format, showing examples, clarifying the owner parameter requires a grant, and noting that value can be any JSON up to 64KB. This goes well beyond the bare schema 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 writes persistent key-value memory scoped to a wallet, which distinguishes it from sibling tools like memory_read and memory_recall. It specifies the resource (memory), action (write/delete), and scope (wallet namespace).
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 explains when to use the tool (write, delete, with TTL) and provides context for cross-namespace writes via the 'owner' parameter. However, it does not explicitly mention when not to use this tool versus siblings like memory_read or memory_remember.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses the tool's nature (live search, read-only), cost ($0.02/call, wallet required), and a critical behavioral trait: results are marked as untrustedContent for analysis only, not to be executed as instructions.
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, each serving a distinct purpose: first introduces the tool and its output, second provides freshness options and a safety warning. It is front-loaded with cost and wallet requirement, making key information immediately visible.
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 the tool's simplicity (3 parameters, no output schema, no annotations), the description covers all necessary aspects: purpose, usage, parameters, return format, cost, and safety. It leaves no critical gaps for an AI 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with brief descriptions. The description adds value beyond the schema by explaining the meaning of freshness filter values (pd/pw/pm/py) and emphasizing the maximum query length (400 chars) and result count range (1-20). This enriches parameter understanding.
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 'Live web search' and details the output format (ranked results with title, URL, snippet, age) and data source ('independent search index'). It distinguishes from sibling tools by specifying real-time access to fresh pages beyond training data.
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 explains when to use the tool (when current information is needed) and provides context on cost and freshness filters. It lacks explicit when-not-to-use or alternative tool references, but the context is clear enough for appropriate selection.
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:

[![Agent402 MCP server](https://glama.ai/mcp/servers/MikeyPetrillo/Agent402/badges/card.svg)](https://glama.ai/mcp/servers/MikeyPetrillo/Agent402)

Score Badge

Copy to your README.md:

[![Agent402 MCP server](https://glama.ai/mcp/servers/MikeyPetrillo/Agent402/badges/score.svg)](https://glama.ai/mcp/servers/MikeyPetrillo/Agent402)

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/MikeyPetrillo/Agent402'

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