Agent402.Tools — pay-per-call web tools
Server Details
400 pay-per-call tools + 100 skill packs. USDC on 8 chains, or free via PoW.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 15 of 15 tools scored.
Each tool has a distinct purpose: utilities like base64, csv_to_json, hash, etc., are clearly separated; even find_tool and search_tools differ in browsing vs. pinpointing. No two tools could be easily confused.
All names follow lowercase snake_case, whether single-word (hash, uuid) or compound (unit_convert, wallet_balances). No mixing of styles, making it predictable.
15 tools is well-scoped for a general utility collection plus MCP infrastructure. Each tool earns its place without feeling bloated or sparse.
The server covers common encoding, conversion, data formatting, and ecosystem-specific tasks (search, call, payment, wallet). No glaring gaps for its stated purpose as a pay-per-call web tool set.
Available Tools
15 toolsbase64Base64ARead-onlyIdempotentInspect
[free, no wallet] Base64 encode or decode text. mode: encode (default) or decode. Handles URL-safe base64 on decode. Returns { mode, result }.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | encode | decode | |
| text | Yes | Input text (max 100KB) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds that it handles URL-safe base64 on decode and returns { mode, result }, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple encoding tool with no output schema, it explains the return format and parameter behavior. Slightly lacking in error handling or limits beyond schema, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description explains mode options and default, and adds information about URL-safe handling on decode, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it does Base64 encoding and decoding, specifies the mode parameter with default, and distinguishes from sibling tools like gzip and hash which handle other encoding types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like gzip or hash. It only describes functionality without context-specific recommendations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
call_toolRun an Agent402 toolARead-onlyIdempotentInspect
Run an Agent402 tool by slug (find slugs with search_tools). The 218 pure-CPU tools execute free on this hosted connector (rate-limited, no wallet — proof-of-work covers them). Wallet-only tools (live market data like stock-quote at $0.003, live search, browser rendering, PDFs, durable memory) return instructions for paid access instead.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tool slug, e.g. "unit-convert" | |
| params | No | Tool input, matching the tool's inputSchema |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds rate-limit info and explains paid tool behavior, enriching transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with core action, no redundant text. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Good completeness given 2 parameters and no output schema. Covers slug discovery, pricing, rate limits. Missing return format but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description only adds that slug can be found via search_tools, not much additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs an Agent402 tool by slug, specifies how to find slugs via search_tools, and distinguishes from sibling tools like search_tools or find_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use context: for running tools by slug, with differentiation between free pure-CPU tools and paid wallet-only tools. Does not explicitly state when not to use but gives adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
csv_to_jsonCSV to JSONARead-onlyIdempotentInspect
[free, no wallet] Parse CSV (quoted fields supported) into a JSON array of objects, using the first row as headers (header=false for arrays). Returns { rows, count }.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | Yes | CSV text (max 100KB) | |
| header | No | First row is headers (default true) | |
| delimiter | No | Default , |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive. The description adds valuable behavioral info: cost-free nature, no wallet required, support for quoted fields, and the behavior of header=false for arrays—going beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with parenthetical clarifications. It front-loads key info (free, no wallet) and avoids any redundant or extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, 100% schema coverage, and absence of output schema, the description covers the essential functionality and return format. It lacks details on error handling or edge cases, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal extra meaning. It does hint that header=false treats the first row as data rather than headers, which is slightly helpful but not critical beyond the existing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Parse', the resource 'CSV text', and the output 'JSON array of objects', with specific details like quoted fields and header handling. It also distinguishes this tool from siblings which are mostly unrelated text operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context like '[free, no wallet]' but does not explicitly state when to use this tool versus alternatives, nor does it give when-not-to-use guidance. It implies usage through the task description but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_toolFind the right Agent402 tool for a taskARead-onlyIdempotentInspect
Describe a task in plain language and get the single best-matching Agent402 tool(s) ready to call: slug, price, input schema, and a worked example. Use this when you know the task and want the top pick (vs search_tools, which browses many candidates by keyword). Returns { task, matches } — each match is call-ready; then run call_tool with the chosen slug + params.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What you want to do, e.g. "extract the article from this url" or "convert miles to km" | |
| limit | No | Max results (default 5) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds that matches are call-ready with slug, price, schema, example, and returns { task, matches }. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the purpose, provide usage guidance, and detail the return value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input, behavior, output structure, and follow-up steps. Without an output schema, it sufficiently describes the return format. For a tool with only 2 parameters and clear annotations, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (task and limit). Description does not add extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it finds the best-matching tool(s) for a plain language task. Distinguishes itself from sibling search_tools by contrasting top pick vs keyword browsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use ('know the task and want the top pick') and when not ('vs search_tools'). Also advises to use call_tool with the chosen slug and params.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hashHashARead-onlyIdempotentInspect
[free, no wallet] Cryptographic hash of a text string. Algorithms: sha256 (default), sha512, sha1, md5. Returns hex and base64 digests. Returns { algo, hex, base64 }.
| Name | Required | Description | Default |
|---|---|---|---|
| algo | No | sha256 | sha512 | sha1 | md5 | |
| text | Yes | Text to hash (max 100KB) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by disclosing output format { algo, hex, base64 }, max input size (100KB), and that the tool is free and requires no wallet. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that convey purpose, cost, algorithms, output format, and input limit. Every word serves a purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 params, no output schema, good annotations), the description covers all necessary context: what it does, input constraints, algorithm choices, output shape, and that it is free and stateless.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds meaning by noting that 'algo' is optional (defaults to sha256) and specifying the output structure, which goes beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a cryptographic hash of a text string, specifies available algorithms (sha256, sha512, sha1, md5), and distinguishes from sibling tools like base64 or gzip by its hashing function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is free and requires no wallet, but does not explicitly state when to use or not use it compared to sibling tools like base64, gzip, or jwt_decode. Usage context is implied but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
json_formatJSON validate & formatARead-onlyIdempotentInspect
[free, no wallet] Validate, pretty-print, or minify JSON. Returns parse errors with position when invalid. Returns { valid, formatted }.
| Name | Required | Description | Default |
|---|---|---|---|
| json | Yes | JSON text to validate/format (max 100KB) | |
| indent | No | Spaces of indentation; 0 = minify (default 2) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: returns parse errors with position, returns {valid, formatted}, and mentions 100KB limit. No contradiction with readOnlyHint, idempotentHint, destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence plus return format. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 2 parameters and no output schema, description fully covers what tool does, its limits (100KB), and return shape. Annotations cover safety aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% already documents both parameters. Description adds meaning: indent=0 means minify (not just default 2), providing context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb+resource: validate, pretty-print, or minify JSON. Distinguishes from sibling json_diff which compares two JSONs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use vs siblings. Purpose is clear but lacks guidance on alternative tools like json_diff.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jwt_decodeJWT decodeARead-onlyIdempotentInspect
[free, no wallet] Decode a JWT without verification: header, payload, expiry status, and time remaining. (Decoding only — signatures are NOT verified.) Returns { header, payload, expired }.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The JWT string |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds valuable context: no verification, returns header/payload/expired, and time remaining. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief and front-loaded, with two sentences that convey all essential information. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description fully covers functionality, return values, and caveats. Annotations complete the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'token' with schema description 'The JWT string'. Description adds 'Decode a JWT' which is already implied by the schema. With 100% schema coverage, baseline 3 is appropriate; no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it decodes a JWT without verification, providing header, payload, and expiry status. It distinguishes from verification tools by explicitly stating 'Decoding only — signatures are NOT verified.' The specific verb+resource and scope are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (decoding only) and when not to use (no verification). However, it does not name an alternative tool for verification, leaving the agent to infer from context. Still effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
markdown_to_htmlMarkdown to HTMLARead-onlyIdempotentInspect
[free, no wallet] Render CommonMark + GFM markdown to HTML. Returns { html }.
| Name | Required | Description | Default |
|---|---|---|---|
| markdown | Yes | Markdown text (max 100KB) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds that it is free, requires no wallet, and returns a specific JSON structure, which provides useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the most important qualifiers ('free, no wallet'), and uses every word effectively without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple conversion tool with no output schema and single parameter, the description completely covers input, output, and cost constraints, making it sufficiently informative for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'markdown' parameter (max 100KB). The main description does not add extra semantic detail beyond what the schema provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders CommonMark + GFM markdown to HTML, specifying the input and output format with '{ html }', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes '[free, no wallet]' to indicate no cost, but lacks explicit comparisons to sibling tools. However, the context of being a straightforward conversion utility is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payment_infoPayment and wallet setupARead-onlyIdempotentInspect
How paying for Agent402 tools works and how to manage a wallet. This hosted connector holds NO wallet: 218 pure-CPU tools run free here (or solve a proof-of-work puzzle), the rest — including the /v1 OpenAI-compatible LLM gateway (chat nano $0.003, embeddings $0.002; no API key, wallet = account) — settle in USDC via x402. Covers: the free vs paid split, how to configure a funded wallet + per-call and budget spend caps, the rails (USDC on Base, Solana, Polygon, Arbitrum, Monad, Stellar, or Algorand - or USDG on Robinhood Chain), and checking a wallet's balance/transaction history via the wallet-balances / wallet-transactions tools. Returns { connector, freeTier, pay, spendControls, balanceAndHistory }.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds context that no wallet is held, free tier exists, and payment rails are detailed. It does not contradict annotations. While it provides ecosystem context, it does not reveal additional behavioral traits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, containing multiple details about payment rails, pricing, and wallet setup. While it is well-structured with clear sections, it could be more concise for an AI agent. It includes information that may be better placed in separate documentation, reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and comprehensive annotations, the description fully explains the tool's purpose, what it covers, and what it returns. It also references sibling tools, making it complete for the agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the input schema, and schema description coverage is 100%. The description adds no parameter information since none are needed. Baseline 4 is appropriate as no additional meaning is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool explains payment and wallet setup for Agent402, covering free vs paid split, wallet configuration, and supported rails. It uses specific verbs like 'covers' and clearly identifies the resource (payment and wallet setup), distinguishing it from sibling tools like wallet_balances and wallet_transactions that handle specific operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions wallet_balances and wallet_transactions as tools for checking balance/history, implying this tool is for overview and setup. However, it does not explicitly state when to use this tool versus alternatives, nor does it exclude scenarios. The guidance is present but could be more direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qrQR codeARead-onlyIdempotentInspect
[free, no wallet] Generate a QR code PNG from any text or URL. ?text=…&size=256 (128-1024). Returns { contentType, body }.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Image width px (128-1024, default 256) | |
| text | Yes | Content to encode (max 2KB) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotent/read-only; description adds output format, size range, and 'free, no wallet' context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, front-loaded with key info, every character serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description's inclusion of return format and size range is critical and mostly sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters with descriptions. Description repeats size range but does not add significant new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates a QR code PNG from text or URL, with specific output format. Distinct from diverse sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates free and no wallet needed, but no explicit when-to-use or when-not-to-use guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_toolsSearch the Agent402 tool catalogARead-onlyIdempotentInspect
Keyword search over Agent402's 504 pay-per-call web tools (live market data like stock-quote at $0.003, encoding, crypto, text, time, math, validation, unit conversions, network, browser, PDF, search, memory). Use this to BROWSE several candidates by keyword; use find_tool instead when you want the single best tool for a described task. 218 pure-CPU tools run free here (proof-of-work — no wallet needed); the rest need a USDC wallet. There is also an OpenAI-compatible LLM gateway at https://agent402.tools/v1 — flat per-call (chat nano $0.003, auto $0.01, embeddings $0.002), no API key: a funded wallet is the account. Returns { results, workflows } — each result has slug, price, access, description, inputSchema; run one with call_tool.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| query | Yes | What you need, e.g. "decode JWT", "miles to km", "cron next run" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds context about free vs paid tools, proof-of-work requirement, wallet needs, and return structure. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph packs maximum information efficiently. Front-loaded with main purpose, every sentence adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return format ({ results, workflows } with field details). Covers scope, pricing, free options, LLM gateway, execution method. Fully complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. Description adds examples for query parameter and explains limit default. Also describes result fields, providing valuable context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it performs keyword search over a catalog of 504 tools. Explicitly distinguishes from sibling 'find_tool' by describing this is for browsing multiple candidates while find_tool returns the single best tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (browse candidates by keyword) and when-not-to-use (use find_tool for single best tool). Also mentions pricing model and free tools, helping agent decide based on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unit_convertUnit convertARead-onlyIdempotentInspect
[free, no wallet] Convert a value between units of length, mass, temperature, volume, area, speed, time, data, pressure, energy, power, angle, frequency — every unit the retired convert-* endpoints handled (e.g. miles, kilograms, us-gallons, fahrenheit, psi, kilowatt-hours). Returns { result, from, to }.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target unit id — must be in the same category as `from`. | |
| from | Yes | Source unit id — any unit of length, mass, temperature, volume, area, speed, time, data, pressure, energy, power, angle, or frequency (e.g. "miles", "fahrenheit", "us-gallons"). Short aliases like "km"/"lb"/"f" also work. | |
| value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, destructiveHint. The description adds 'free, no wallet' and the return format, which are useful beyond annotations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical list, efficiently conveying all key information without wasted words. It is front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description mentions the return format. It covers the main behavior and categories, but could add error handling or precision details. Still fairly complete for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% with descriptions for 'from' and 'to' but not 'value'. The description provides examples of units and mentions short aliases, adding some value but not fully compensating for the undocumented 'value' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts a value between units, lists many categories, and references the retired convert-* endpoints, making it specific and distinguishable from sibling conversion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'free, no wallet' implying no cost, but does not explicitly state when to use vs. alternatives. However, the unit categories are comprehensive, and sibling tools cover different conversion types, providing implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uuidUUID generatorARead-onlyIdempotentInspect
[free, no wallet] Generate UUIDs. ?version=4 (default, random) or 7 (time-ordered), ?count=1..100. Returns { version, uuids }.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many (1-100, default 1) | |
| version | No | 4 (random) or 7 (time-ordered) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds value by stating it's free and no wallet required, and specifies return format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with key info front-loaded ('[free, no wallet]'). Every part is essential, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, description covers generation, version, count, and return format. Complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context like 'default, random' for version and '1..100' for count, but these are already in schema descriptions. Minimal extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Generate UUIDs' and specifies version options (4 or 7) and count range. It is distinct from sibling tools which are all different utilities, so no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (generating UUIDs) but does not explicitly state when not to use or provide alternatives. Given the simplicity and standard nature of UUID generation, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wallet_balancesWallet token balances (indexed)ARead-onlyIdempotentInspect
[wallet-required, $0.002/call] All token balances for any address in one call, from Coinbase's indexed data API — ERC-20 + native on EVM, SPL on Solana; no per-token contract calls, no RPC wrangling. Networks: base, ethereum, base-sepolia, solana, solana-devnet. Symbols/decimals populated for whitelisted tokens (USDC always included). Returns { address, network, balances, count }. This hosted connector holds no wallet, so calling it here returns paid-access setup; run it with a funded wallet via npx agent402-mcp or any x402 client.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet address — EVM 0x… or Solana base58, matching the network | |
| network | No | base (default) | ethereum | base-sepolia | solana | solana-devnet |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. The description adds that the tool returns { address, network, balances, count } and that symbols/decimals are provided for whitelisted tokens. It also reveals that calling it in this environment returns a paid-access setup note, which is important 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose but well-structured: it front-loads the main benefit, then lists networks, return format, and usage note. Every sentence adds value, though minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully compensates for the lack of output schema by detailing the return format and token behavior. It also covers the limitation about the hosted connector, making it complete for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds clarity on address format (EVM 0x... or Solana base58) and network defaults (base as default), providing extra semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all token balances for any address in a single call, using Coinbase's indexed API. It explicitly distinguishes from per-token contract calls and RPC wrangling, and lists supported networks and tokens. The purpose is specific and distinct from siblings like wallet_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (get all balances in one call, avoid per-token calls) and provides context about the hosted connector requiring a funded wallet. It doesn't explicitly compare to wallet_balance, but the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wallet_transactionsWallet transaction historyARead-onlyIdempotentInspect
[wallet-required, $0.002/call] Return the most recent asset transfers (incoming + outgoing) for a wallet address — native coin, ERC-20, ERC-721, ERC-1155 — already merged and sorted newest first. Each row carries the block, tx hash, counterparty, asset, and decimal value. Cap is 100 per direction; widen the window via fromBlock if you need deeper history. Returns { address, network, limit, transfers }. This hosted connector holds no wallet, so calling it here returns paid-access setup; run it with a funded wallet via npx agent402-mcp or any x402 client.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max transfers per direction (1-100, default 25). | |
| address | Yes | 0x-prefixed 40-char hex wallet address. | |
| network | No | ethereum / base / polygon / arbitrum / optimism (default base). | |
| fromBlock | No | Optional starting block in hex (default 0x0 = earliest). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: merges and sorts transfers, lists returned fields (block, tx hash, etc.), specifies cap per direction. No contradiction with annotations (readOnlyHint, idempotentHint).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with core functionality. Includes necessary context (cost, setup) but some meta info (hosted connector note) could be trimmed. Each sentence adds value but slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return structure, limits, and parameter usage adequately. No output schema, but description explains output fields. Lacks error handling details, but sufficient for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description enhances meaning for limit and fromBlock by explaining the cap and widening window. Address and network are already clear from schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'return' and resource 'asset transfers for a wallet address', specifying multiple asset types. It distinguishes from sibling tools by focusing on transaction history vs balance tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage guidance like cap per direction and using fromBlock for deeper history. Also notes the hosted connector limitation. However, it does not explicitly contrast with sibling tools like wallet_balance or provide when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!