Agent402.Tools — pay-per-call web tools
Server Details
400+ pay-per-call tools + 100 skill packs. USDC + USDG on 10 chains, or free via PoW.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- MikeyPetrillo/Agent402
- GitHub Stars
- 5
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.4/5 across 15 of 15 tools scored. Lowest: 3.8/5.
Each tool has a clearly distinct purpose. For example, convert_* tools handle unit conversions separately, search_tools vs find_tool are differentiated (search lists candidates, find resolves to one), and generate_* tools cover different formats. No overlapping functionality.
All tool names follow a consistent verb_noun pattern with underscores (e.g., convert_units, generate_hash, get_wallet_balances). No mixing of camelCase or other conventions, making the naming predictable and easy to parse.
With 15 tools covering a wide range of common utility tasks (conversions, hashing, QR codes, CSV parsing, etc.) plus a meta-tool (call_tool) and discovery tools, the count feels appropriate for a general-purpose web tools server. It is neither too sparse nor bloated.
The tool set includes essential utilities like conversions, hashing, JWT decoding, JSON/CSV formatting, and UUID generation. However, some paid tools (e.g., stock quote, browser rendering) are not directly usable as they return setup guides, and there is no tool for XML or advanced data manipulation. Minor gaps exist but do not severely hinder common workflows.
Available Tools
15 toolscall_toolRun an Agent402 toolARead-onlyIdempotentInspect
Run an Agent402 tool by slug (discover slugs with search_tools or find_tool; params must match that tool's inputSchema). The 220 pure-CPU tools execute free on this hosted connector (rate-limited, no wallet - proof-of-work covers them) and return the tool's JSON result. Wallet-only tools (live market data like stock-quote at $0.003, live search, browser rendering, PDFs, durable memory) return a paid-access setup guide instead - this connector holds no wallet. An unknown slug returns an error pointing back to search_tools.
| 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 context: free tools are rate-limited and use proof-of-work, paid tools return a guide. It also explains error behavior for unknown slugs. Adds value 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 a single paragraph but well-organized, covering key points in a logical order. Could be slightly more concise, but every sentence 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?
Given no output schema, the description fully explains return values (JSON result for free tools, setup guide for paid). Handles error cases (unknown slug). With sibling tools and full schema coverage, it 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%, so baseline is 3. Description adds value by explaining how to discover slugs and that params must match the tool's inputSchema. It provides context beyond the schema definitions.
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 runs an Agent402 tool by slug, distinguishes from sibling tools like search_tools and find_tool for discovery, and explains the two categories of tools (free vs wallet-only). It uses specific verbs and resources.
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 (to run a tool by slug) and when not (wallet-only tools return a setup guide). References siblings for slug discovery and error handling, providing clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_base64Base64ARead-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?
Description adds value beyond annotations: it specifies handling of URL-safe base64 on decode and the return shape { mode, result }. Annotations already indicate read-only, idempotent, non-destructive.
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 with zero wasted words. Front-loads key constraints ('free, no wallet') and covers purpose, modes, and return format efficiently.
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 and no output schema, the description covers input constraints, modes, and return shape. Missing error handling but acceptable for such a 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. Description adds default value for mode and context about URL-safe handling during decode, providing marginal extra meaning.
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 encodes or decodes Base64 text, which is unambiguous. While it doesn't explicitly differentiate from siblings like decode_jwt or generate_hash, the purpose is distinct enough.
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' indicating cost-free usage, and notes default mode. However, it lacks explicit guidance on when to use this tool versus alternatives like decode_jwt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_timezoneTimezone convertARead-onlyIdempotentInspect
[free, no wallet] Convert a datetime from one IANA timezone to another. Accepts ISO 8601, Unix timestamps (seconds or milliseconds), or natural date strings. Returns the converted time in both timezones with UTC offset. ?datetime=2026-06-23T14:00:00&from=America/New_York&to=Asia/Tokyo. Returns { input, from, to, utc }.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target IANA timezone (e.g. Asia/Tokyo) | |
| from | Yes | Source IANA timezone (e.g. America/New_York) | |
| datetime | Yes | Datetime to convert (ISO 8601, Unix timestamp, or natural date string) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark as read-only, idempotent, and non-destructive. Description adds that it's free, lists input formats, and specifies return structure (input, from, to, utc). Does not describe error handling or edge cases, but sufficient 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?
Single paragraph with no waste; front-loaded with purpose, then details. Example and return structure are efficiently presented.
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 3 required parameters and no nested objects, the description fully covers input formats, output fields, and example usage. No missing context.
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 has 100% coverage with descriptions. Description adds value by detailing acceptable datetime formats (ISO 8601, Unix timestamps, natural date strings) and showing an example, going 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 'Convert a datetime from one IANA timezone to another' with specific verb and resource. Distinguishes from sibling tools like convert_units or convert_base64 by focusing on timezone conversion.
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 usage and no wallet requirement, plus provides an example query. However, lacks explicit when-to-use or when-not-to-use guidance against alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_unitsUnit 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 read-only, idempotent, non-destructive behavior. The description adds value by stating it is '[free, no wallet]' and detailing the return object '{ result, from, to }', providing cost and output structure 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. The first covers purpose and scope, the second details return format. Front-loaded with key information, 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?
For a simple conversion tool with 3 parameters and no output schema, the description covers inputs, output format, and unit categories. It lacks error handling details, but overall is sufficiently 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 description coverage is 67% (value parameter undecorated). The description adds category examples and notes unit aliases, supplementing the schema's descriptions for 'from' and 'to'. While it does not explain 'value', the overall context is sufficient.
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 values between units across multiple categories (length, mass, temperature, etc.) and specifies the return format. It distinguishes itself from sibling tools like convert_base64 and convert_timezone by focusing on unit conversions.
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 the tool is free and requires no wallet, and lists the unit categories. It implicitly indicates use for unit conversions versus other conversion tools, but 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.
decode_jwtJWT 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?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds the return format and clarifies that signatures are not verified. It also states the tool is free and requires no wallet. This provides good behavioral context without contradicting any 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, fitting into one sentence with a parenthetical clarification and a quick return type. Every phrase adds value, and key information is front-loaded with '[free, no wallet]'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and full annotations, the description covers purpose, behavior, output format, and cost. The mention of 'time remaining' is present but does not appear explicitly in the return format, creating a minor ambiguity. Overall, it is sufficiently 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% and the single parameter 'token' is adequately described as 'The JWT string' in the schema. The description does not add further semantic detail beyond what the schema provides, so baseline 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 specifies the action (decode), the resource (JWT), and the outputs (header, payload, expiry status, time remaining). It explicitly distinguishes from verification, making the tool's scope 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 provides context on when to use ('free, no wallet') and explicitly states signatures are not verified. However, it does not explicitly mention alternative tools or conditions when this tool should not be used, though the sibling tools list offers no direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_toolResolve a task to the one best Agent402 toolARead-onlyIdempotentInspect
DECIDE, don't browse: resolve a plain-language task to the single best-matching Agent402 tool, returned call-ready - slug, price, input schema, and a worked example (its counterpart search_tools returns a list of candidates to compare - search explores, find decides). Returns { task, matches } with the top pick first; 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?
The description adds significant behavioral context beyond the annotations. It explains the output includes 'slug, price, input schema, and a worked example' and describes the return format. It is consistent with the annotations (readOnlyHint, idempotentHint, destructiveHint) and provides a clear usage flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two well-structured sentences. The core purpose is front-loaded ('DECIDE, don't browse'), and each part serves a purpose: stating the action, contrasting with sibling, describing the output, and suggesting next steps. No wasteful 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 moderate complexity, the description covers all necessary aspects: purpose, when to use vs sibling, output format, and how to proceed after receiving the result. The parameter schema is fully documented, and while there is no output schema, the description adequately describes the output structure. The tool is well-contextualized for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description does not add any additional parameter-specific details beyond what is in the schema. At baseline, a score of 3 is appropriate when the schema carries the full burden.
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 'resolve' and the resource 'plain-language task to the single best-matching Agent402 tool'. It also distinguishes the tool from its sibling 'search_tools' by contrasting their behaviors: 'search explores, find decides'. This leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidelines: 'DECIDE, don't browse' and contrasts with 'search_tools' for exploratory comparisons. It also explains the output is 'call-ready' and instructs to use the result with 'call_tool', making it clear when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
format_jsonJSON 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?
Beyond annotations (readOnly, idempotent, non-destructive), the description adds important details: free/no wallet cost, parse error positions on invalid input, and the return structure { valid, formatted }. This exceeds annotation information.
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: two sentences that earn their place. No wasted words, front-loaded with key action and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers return structure and error behavior. Could mention that 'formatted' is a string, but overall complete 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 coverage is 100%, so baseline 3. Description mentions 'minify' corresponding to indent=0 but adds little beyond schema definitions. Adequate but not enhanced.
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 validates, pretty-prints, or minifies JSON, using specific verbs and resource. It distinguishes well from sibling tools like convert_timezone or decode_jwt which handle other formats.
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?
While no explicit 'when to use' or alternatives are given, the purpose is so clear that an agent can infer usage. Lacks exclusion notes but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context like 'free, no wallet' and specifies the return format, which goes 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, using two sentences to convey all necessary information. It is front-loaded with the crucial 'free, no wallet' note, making it efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully specifies the return format. The tool is simple, and the description covers all key aspects (algorithms, input constraints, output structure).
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 both parameters described. The description adds value by noting that sha256 is the default algorithm and that text has a 100KB max, providing practical usage hints.
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 performs a cryptographic hash of a text string, lists the supported algorithms, and specifies output formats. This distinguishes it from sibling tools like convert_base64 or generate_uuid.
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, implying it's safe for any use. However, it doesn't explicitly state when to use this tool versus alternatives, but given its simplicity, the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the return format '{ contentType, body }' and size range '128-1024', providing useful behavioral context beyond the 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 a single sentence with parenthetical details, delivering all essential information without waste. It is front-loaded with the key action and output format.
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 2 parameters, no output schema, and no nested objects, the description covers input, output format, and size range. It does not address error behavior or max content size beyond the schema, but is adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description mirrors the schema by showing placeholder usage (?text=…&size=256) and mentioning the size range, but adds no significant new meaning beyond what the schema 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?
The description clearly states 'Generate a QR code PNG from any text or URL', specifying the verb (generate), resource (QR code), output format (PNG), and input type. It distinguishes from sibling tools like generate_hash and generate_uuid.
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]' implying no prerequisites, and provides a usage pattern (?text=…&size=256). However, it does not explicitly state when to use or not use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_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 provide safety hints (readOnly, idempotent, non-destructive). The description adds context about free usage, no wallet, and the return format, which goes 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 a single sentence that efficiently conveys free status, action, parameters, and return format with 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?
For a simple UUID generation tool with thorough schema and annotations, the description covers all necessary aspects: purpose, parameters, and return format, leaving no gaps.
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%, but the description clarifies default values and valid ranges for version and count, adding value beyond the schema descriptions.
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 'Generate UUIDs' with specific version options and count range, effectively distinguishing it from sibling tools like generate_hash or generate_qr.
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 it's free and no wallet needed, providing context, but lacks explicit guidance on when to use this tool over alternatives. It implies usage for UUID generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_payment_infoPayment and wallet setupARead-onlyIdempotentInspect
How paying for Agent402 tools works and how to manage a wallet. This hosted connector holds NO wallet: 220 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, Celo, Avalanche, 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 declare readOnlyHint=true and idempotentHint=true, so the description's behavioral disclosure is minimal. However, it adds valuable context about the hosted connector holding no wallet and the free/payment split. No contradictions 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?
The description is informative but relatively long (multiple sentences). It front-loads the purpose and covers all necessary aspects, but could be slightly more concise. Still, 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?
Given the tool has no parameters and no output schema, the description fully explains the tool's purpose, the return object structure, and related tools. It is self-contained and provides all necessary context.
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?
There are no parameters (schema coverage 100%), so baseline is 4. The description adds meaning by explaining what the return object contains, which compensates for the lack of parameters and output 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 what the tool does: it explains how paying for Agent402 tools works and how to manage a wallet, returning a specific object. It distinguishes itself from sibling tools like get_wallet_balances and get_wallet_transactions by explicitly covering payment setup and spending controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: for understanding the free vs paid split, configuring a funded wallet, and checking balance/history via sibling tools. It also clarifies the payment rails and includes alternative tools for wallet details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_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?
Description adds value beyond annotations by disclosing cost ($0.002/call), that symbols/decimals are populated only for whitelisted tokens (USDC always), and that the connector holds no wallet. No contradiction with readOnlyHint and destructiveHint. IdempotentHint is consistent with a read-only operation.
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 packed into a few sentences with key information front-loaded (purpose, benefits, networks, returns). Some sentences are dense but still readable. Could be broken into shorter segments for clarity, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, input parameters, pricing, and return shape ({ address, network, balances, count }). However, it does not detail the structure of 'balances' (e.g., array of objects with fields like token, balance, decimals). Given no output schema, a bit more detail would be beneficial, but still fairly complete for a read-only tool with good annotations.
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 minor context: address must match network, network defaults to 'base', but does not provide syntax details beyond what the schema already specifies. No additional parameter semantics to elevate score.
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 the tool retrieves all token balances for any address in one call from Coinbase's indexed data API, covering ERC-20 + native on EVM and SPL on Solana. It distinguishes from sibling tools like get_wallet_transactions by focusing on balances and emphasizing efficiency (no per-token calls, no RPC wrangling).
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?
Description mentions that the connector holds no wallet, so calling it without a funded wallet returns paid-access setup, and recommends using a funded wallet via npx agent402-mcp. It implies when to use (for comprehensive balance queries) but does not explicitly state when not to use or provide alternatives beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds context about the hosted connector returning paid-access setup and needing a client, which goes 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 paragraphs with core purpose first, then details. No redundant sentences or 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?
No output schema, but description mentions output structure. With 4 parameters and no enums, the description is sufficiently 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%, baseline 3. Description adds value by explaining the cap per direction for limit, widening via fromBlock, and output structure { address, network, limit, transfers }.
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 returns asset transfers for a wallet, listing asset types, sorting, and output structure. It distinguishes from sibling get_wallet_balances by focusing on transfers.
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 describes when to use (for transfers), mentions a cap per direction and how to widen via fromBlock, and notes hosting limitation requiring a funded wallet. Lacks explicit exclusion of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_csvCSV 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 read-only, idempotent, non-destructive. Description adds valuable context: free usage, no wallet required, max 100KB input, quoted fields support, header behavior, and return format. 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?
Single sentence efficiently packs key info: cost, syntax support, header behavior, return shape. Front-loaded with cost/access context in brackets.
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?
Tool is simple with 3 params and no output schema. Description covers main behavior and return value. Could mention delimiter default or error handling, but overall 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 descriptions cover all 3 parameters (100% coverage). Description adds extra meaning: 'header=false for arrays' clarifies the boolean behavior, and implies the max size constraint for csv field.
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 (Parse), resource (CSV), output (JSON array of objects), and key behaviors (first row as headers, optional header=false for arrays, return format { rows, count }). Distinct from siblings which are other utilities.
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?
Purpose is specific enough that usage context is clear (parse CSV to JSON). No explicit when-not-to-use or alternatives, but tool name and description make it obvious.
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
BROWSE the catalog: keyword search over Agent402's 516 pay-per-call web tools, returning a LIST of candidates to compare (its counterpart find_tool resolves a task to ONE ready-to-run pick - search explores, find decides). Categories: live market data (stock-quote at $0.003), encoding, crypto, text, time, math, validation, unit conversions, network, browser, PDF, search, memory. 220 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. Beyond this catalog, Agent402 can ROUTE-AND-EXECUTE against the OPEN x402 ecosystem: POST https://agent402.tools/api/route/execute with { task, include:"external" } resolves a PROVEN external seller (real settled volume), pays it on your behalf, and relays the result (marked untrustedContent) - one call to reach thousands of outside tools, from a $0.01 flat fee. That path is wallet-only, so run it with your own wallet via the HTTP API or the stdio agent402-mcp package's route_and_execute tool (this hosted connector holds no wallet). 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?
The description adds significant behavioral context beyond annotations: it details the returned structure (results, workflows), explains pricing categories, highlights that 218 tools are free (proof-of-work), and mentions an LLM gateway. This fully discloses the tool's behavior without contradicting the readOnlyHint and 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?
The description is moderately concise and well-structured, starting with the main purpose, then differentiating from sibling, then providing context on categories, pricing, and return format. While slightly dense, every sentence adds value, earning a 4.
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 absence of an output schema, the description compensates by specifying the return shape ({ results, workflows }) and explaining result fields (slug, price, etc.). It covers pricing and free tools, but does not detail pagination or error handling, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (query and limit) with clear descriptions. The tool description adds marginal value for parameters, only reinforcing the query purpose with examples. Since schema coverage is 100%, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as browsing the catalog with keyword search, returning a list of candidates. It explicitly distinguishes its purpose from the sibling find_tool ('search explores, find decides'), providing high purpose clarity.
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 gives explicit guidance on when to use this tool: for exploring and comparing multiple candidates, versus find_tool for a single ready-to-run pick. It also provides context about free vs paid tools and the LLM gateway, aiding proper selection.
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!