Agent402.Tools — pay-per-call web tools
Server Details
1,407 pay-per-call tools + 100 skill packs. USDC on 6 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.1/5 across 17 of 17 tools scored. Lowest: 3.5/5.
Each tool has a clearly distinct purpose spanning encoding, crypto, text, time, search, and utilities. The only possible overlap is between search_tools and find_tool, but descriptions clarify that search_tools returns slugs by keyword, while find_tool takes a natural language task description. No tools compete for the same job.
Most tool names use a consistent lowercase hyphenated pattern (e.g., json-diff, timezone-convert), but a few use underscores (search_tools, stats_summary) or are single words (gzip, hash, qr). The convention is mostly predictable, with minor deviations.
17 tools for a pay-per-call web utilities server is well-scoped. It covers a broad range of common tasks without being overwhelming. Each tool earns its place, and the count aligns with typical utility servers (3-15 is fine, this is slightly above but still reasonable).
The free tier covers many common utilities (encoding, crypto, text, time, math, units), but notable features like browser rendering, PDF generation, live search, and persistent memory are explicitly walled behind payment. This creates clear gaps for agents expecting full offline capability, though the paid tools are discoverable via search_tools.
Available Tools
17 toolsabout_agent402About this connectorARead-onlyIdempotentInspect
What this connector is: the free tier of agent402.tools, what's free vs wallet-only, the curated multi-tool workflows (skill packs) available as prompts, and how paid access works (x402 — USDC on Base/Solana/Polygon/Arbitrum/Stellar, USDG on Robinhood Chain — plus proof-of-work).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only safe operation, and description adds detail on the topics covered, enhancing transparency without 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 sentence is dense and runs on, could be more structured with bullet points or shorter sentences.
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 parameters and no output schema, the description fully covers the tool's informational purpose and key topics.
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, so baseline 4; description adds value by explaining what the tool returns, compensating for lack of 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 that the tool explains the free tier, wallet-only features, skill packs, and payment methods, distinguishing it from sibling utility 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?
Implied usage for obtaining system information, but no explicit when-to-use or alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
base64Base64ARead-onlyIdempotentInspect
[free] Base64 encode or decode text. mode: encode (default) or decode. Handles URL-safe base64 on decode.
| 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, idempotentHint, etc. Description adds 'free', max 100KB input, and URL-safe handling on decode, which is useful 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?
Single sentence, concise, front-loaded with action and details. 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?
No output schema, but for a simple encode/decode the description implies string output. Sufficient context for an AI 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 covers 100% of parameters with descriptions. Description adds default mode ('encode') and URL-safe decode behavior, enhancing 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?
The description clearly states the tool does base64 encoding/decoding, with mode default and URL-safe handling. It distinguishes from sibling tools like gzip and hash by specifying its specific operation.
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 over siblings (e.g., gzip, hash). No context on when to prefer base64 over other encodings.
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 1181 pure-CPU tools execute free on this hosted connector (rate-limited). Wallet-only tools (live search, browser rendering, PDFs, durable memory) return instructions for paid access instead.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tool slug, e.g. "convert-miles-to-kilometers" | |
| 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 readOnlyHint=true and destructiveHint=false, so the description's mention of 'execute' is consistent. It adds transparency about rate-limiting, free vs. paid access, and that wallet-only tools return instructions, which provides valuable 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 concise at three sentences, with the main action stated first, followed by essential distinctions. Every sentence adds value, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, nested object, no output schema), the description covers the essential information: what it does, how to find slugs, and the free/paid split. It lacks details about return values or error handling, but these are not critical for an agent to decide to use it. The description is complete enough for its 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?
The input schema has 100% description coverage for both parameters, and the description enhances the slug parameter by pointing users to search_tools to find valid values. It does not add extra detail for the params object, but the schema already describes it. This adds sufficient value over 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 the tool's purpose: to run an Agent402 tool by slug. It also directs users to search_tools for finding slugs and distinguishes between pure-CPU (free) and wallet-only (paid) tools, differentiating it from sibling tools like search_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 provides guidance on when to use this tool (to execute tools) and how to find the required slug using search_tools. It explains the free/paid distinction, but does not explicitly state when not to use it or list alternatives, which keeps it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cron-nextCron next runsARead-onlyIdempotentInspect
[free] Parse a 5-field cron expression and return the next N run times (UTC).
| Name | Required | Description | Default |
|---|---|---|---|
| expr | Yes | 5-field cron: minute hour day-of-month month day-of-week | |
| from | No | Start time (epoch/ISO, default now) | |
| count | No | How many upcoming runs (1-20, default 5) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate these. It adds useful context: the tool is free and returns times in UTC. 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 a single, front-loaded sentence that conveys all essential information without extraneous words. It is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with good annotations and full schema coverage, but the description does not detail the return format (e.g., array of ISO strings) or handle edge cases. Some additional detail about the output would improve completeness.
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 each parameter already has a description in the schema. The tool description adds no further semantic detail beyond that, meeting the baseline expectation.
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 purpose: parse a 5-field cron expression and return the next N run times in UTC. The verb 'Parse' and resource 'cron expression' are specific, and the tool's function is distinct from siblings like timezone-convert or base64.
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 does not explicitly provide when to use this tool or when to consider alternatives. Usage is implied ('parse a cron expression'), but no guidance on prerequisites or exclusions is given.
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 best-matching Agent402 tool(s) ready to call — slug, price, input schema, and an example — so you skip searching/exploring. 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 indicate readOnly and non-destructive. Description adds context about return values and workflow, but does not disclose any potential side effects or limitations 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?
Description is a single sentence that conveys necessary information, though slightly lengthy; 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?
No output schema, but description explicitly lists return fields (slug, price, input schema, example) and provides a clear workflow, making it complete for a discovery 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 reiterates 'task' and implies 'limit' via 'Max results (default 5)' but adds no additional semantic meaning beyond schema examples.
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 verb 'describe a task' and resource 'Agent402 tool(s)', and distinguishes from siblings by specifying it finds best-matching tools with slug, price, input schema, and example, unlike search_tools which may only list.
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 implies when to use (to skip searching/exploring) and provides a workflow (then call call_tool), but does not explicitly state when not to use or compare to search_tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gzipGzip compressARead-onlyIdempotentInspect
[free] Compress a string with gzip (RFC 1952) and return it as base64. Reports input bytes, output bytes, and the compression ratio so you can decide if it was worth doing. Input can be plain text (utf8) or already-binary content (base64 or hex).
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Content to compress (max 10MB after decoding) | |
| level | No | Compression level 1-9 (default 9 = best ratio, slower) | |
| inputFormat | No | How `input` is encoded: utf8 (default), base64, or hex |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description explains input format flexibility and max size (10MB after decoding). It clarifies pure transformation behavior and reporting metrics, adding useful 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?
Two sentences: first states core action, second adds details on reporting and input formats. No wasted words, appropriately front-loaded.
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 sufficiently explains return (base64 with metrics). Annotations cover safety traits. For a simple compression tool, all necessary context is provided.
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 description adds value by noting max input size and default level behavior (best ratio, slower). It reinforces that input can be utf8, base64, or hex, matching schema but providing context.
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 compresses a string with gzip (RFC 1952) and returns it as base64. It mentions reporting input/output bytes and compression ratio, distinguishing it from siblings like base64, hash, and qr which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for compression to reduce size and assess worth via ratio, but it does not explicitly compare to alternatives or state when not to use it. Lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hashHashARead-onlyIdempotentInspect
[free] Cryptographic hash of a text string. Algorithms: sha256 (default), sha512, sha1, md5. Returns hex and base64 digests.
| 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 indicate read-only, idempotent, non-destructive behavior. Description adds input size limit (100KB) and return format details, providing 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?
Extremely concise single sentence with all key info front-loaded (free, cryptographic hash, algorithms, return formats). Zero 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?
Given simple tool with no output schema, description fully explains functionality, constraints, and outputs. Suitable for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds algorithm options and return digests list, exceeding schema information.
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's a cryptographic hash function, lists supported algorithms, and specifies return formats (hex and base64). Easily distinguishes from sibling tools like base64 or gzip.
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 implies use for hashing text but lacks explicit when-to-use or when-not-to-use guidance, and does not mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
json-diffJSON diffARead-onlyIdempotentInspect
[free] Deep-compare two JSON values. Returns a list of changed/added/removed paths (capped at 1000 differences).
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First JSON value | |
| b | Yes | Second JSON value |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral details: deep comparison and a cap of 1000 differences, which go 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 sentence with a parenthetical, front-loaded with key action and outcome. No unnecessary words; every part contributes to understanding.
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 basic function but lacks details on output format (e.g., path notation), order of differences, or edge cases. With no output schema, more specificity would be beneficial.
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 both parameters as 'First JSON value' and 'Second JSON value'. Description reinforces that they are JSON values but adds no further constraints or formats. Baseline 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'deep-compare', the resource 'two JSON values', and the output 'list of changed/added/removed paths'. It distinguishes from sibling tools like json-format by focusing on diffing.
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?
Implies usage for comparing JSON values, but no explicit when to use or alternatives. No mention of when not to use or comparison with json-format or other tools.
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] Validate, pretty-print, or minify JSON. Returns parse errors with position when invalid.
| 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by noting that it returns parse errors with position when invalid. 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 two sentences, front-loaded with key operations, and contains no filler. 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 good annotations and full schema coverage, the description is complete. It covers error handling, and the return format (formatted JSON or errors) is implied, so no output schema is needed.
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%, providing a baseline of 3. The description adds maximum size for the json parameter and a default for indent, offering 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?
The description clearly states the tool validates, pretty-prints, or minifies JSON, with a specific verb (validate/format) and resource (JSON). It distinguishes from siblings like json-diff which does diffing.
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 for formatting and validation, and mentions error handling. However, it lacks explicit guidance on when not to use it versus alternatives like json-diff or other tools.
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] Decode a JWT without verification: header, payload, expiry status, and time remaining. (Decoding only — signatures are NOT verified.)
| 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, destructiveHint), the description adds that it decodes the JWT to reveal header, payload, expiry status, and time remaining, and explicitly states that signatures are NOT verified. This provides valuable behavioral context about what the tool does and does not do.
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 clarification, containing no redundant words. It is front-loaded with the key action and free indicator, and every part 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?
For a simple tool with one parameter, rich annotations, and no output schema, the description fully captures the input requirements, output contents (header, payload, expiry, time remaining), and the important limitation (no verification). It leaves 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 description coverage is 100% with the parameter 'token' described as 'The JWT string'. The description adds no further detail about the parameter beyond what the schema already provides, so it meets the baseline of 3 without adding 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 verb 'decode' and the resource 'JWT', specifying what it returns: header, payload, expiry status, and time remaining. It also distinguishes itself from verification by explicitly stating 'signatures are NOT verified', which helps differentiate it from any potential 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?
The description provides clear context that this tool is for decoding only and does not verify signatures, so an agent knows not to use it when verification is needed. However, it does not explicitly name alternative tools or provide when-not-to-use guidance beyond the verification limitation.
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] Generate a QR code PNG from any text or URL. ?text=…&size=256 (128-1024).
| 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 convey readOnlyHint, idempotentHint, and destructiveHint. The description adds minimal behavioral context beyond noting it's free and generates a PNG. No disclosure of rate limits, authentication, or output format specifics.
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 (one line) and front-loaded with the core function. Every character 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 tool with 2 parameters and no output schema, the description covers the basic purpose and parameter usage. However, it lacks details about output format (PNG binary) and potential constraints like size limits beyond the schema.
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 description adds only minor utility (e.g., size range hint). Baseline 3 is appropriate as the description does not significantly enhance parameter understanding 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 generates a QR code PNG from any text or URL, using a specific verb and resource. It distinguishes itself from sibling tools like base64 or gzip.
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 an example invocation pattern (?text=...&size=256), implying usage, but does not provide explicit context on when to use this tool versus alternatives or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
readability-scoreReadability scoreARead-onlyIdempotentInspect
[free] Compute Flesch-Kincaid Grade Level, Flesch Reading Ease, Gunning Fog Index, and Automated Readability Index from text. Returns all 4 scores plus word, sentence, and syllable counts.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to analyze (min 10 chars) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output (all 4 scores plus counts) which the user/agent needs to know. Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe nature is clear. The description adds value by specifying exactly what is returned, going beyond the structured 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 that front-loads the free tag and immediately states the action and results. Every part is necessary: the list of indices, the return values. 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?
Given there is no output schema, the description fully specifies what the tool returns (four readability scores and three counts). The tool has a single parameter, and the description covers the behavior and output comprehensively. The annotations cover safety aspects, so nothing is missing.
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 has 100% coverage with a clear description for the 'text' parameter: 'Text to analyze (min 10 chars)'. The tool description does not add additional parameter semantics beyond listing the indices computed. With complete schema documentation, 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 states the tool computes four specific readability indices (Flesch-Kincaid Grade Level, Flesch Reading Ease, Gunning Fog Index, Automated Readability Index) and returns them along with word, sentence, and syllable counts. It uses a specific verb 'Compute' and resource 'readability indices', and the uniqueness of this functionality among sibling tools (mostly text encoding, hashing, etc.) makes it well-distinguished.
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 that this tool is for computing readability scores from text. While it doesn't explicitly state when not to use it or list alternatives, the tool's purpose is straightforward and no sibling tool offers similar functionality. The '[free]' prefix hints at no cost. A score of 4 is appropriate as it adequately implies usage without explicit exclusions.
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
Search Agent402's 1407 pay-per-call web tools (encoding, crypto, text, time, math, validation, unit conversions, network, browser, PDF, search, memory). 1181 pure-CPU tools run free right here; the rest need a USDC wallet. Returns slugs + input schemas for 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, idempotentHint, destructiveHint. The description adds value by disclosing payment requirements for some tools and the return format, which are not covered by 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 with clear structure: first defines scope, second adds detail. No fluff, but could be slightly more succinct. Still 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?
Returns format is explained, payment context is given. Missing output schema but description compensates. No mention of pagination or errors, but adequate for a search 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 adds example query values and mentions limit default, but these are already in the schema. Minimal 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 it searches Agent402's tool catalog, lists tool categories, and specifies the return format (slugs + input schemas). This goes beyond the name and title, providing specific verb and resource scope.
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 some context (free vs paid tools) but does not explicitly guide when to use this tool over alternatives like 'find_tool'. Sibling differentiation is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stats-summaryStats summaryARead-onlyIdempotentInspect
[free] Compute the full descriptive-stats panel for an array of numbers in one call: count, sum, mean, median, mode, stddev (sample), variance, min, max, range, q1, q3, IQR. Beats calling 12 separate tools when you already have the array in front of you.
| Name | Required | Description | Default |
|---|---|---|---|
| values | Yes | Non-empty array of numbers (max 10000) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds value by listing all output statistics, but does not discuss error handling or edge cases beyond the schema's max 10000. 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?
Two efficient sentences: first lists all outputs, second gives usage rationale. No wasted words, front-loaded with key information.
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?
Adequate for a simple tool: lists outputs, annotations cover safety. Lacks return format description and error handling details (e.g., invalid numbers). No output schema to compensate.
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 provides full description for the 'values' parameter (non-empty array, max 10000). Description adds minimal extra context ('when you already have the array') but no format or examples. With 100% schema coverage, 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?
Description clearly states the tool computes a full set of descriptive statistics for an array of numbers, listing 13 specific statistics. Verb 'Compute' plus resource 'descriptive-stats panel' makes purpose specific and distinct from 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?
Description says 'Beats calling 12 separate tools when you already have the array in front of you,' implying use when needing multiple stats and having the data ready. It does not explicitly state when not to use or list alternative tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
timezone-convertTimezone convertARead-onlyIdempotentInspect
[free] 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.
| 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 already indicate readOnly, idempotent, non-destructive. The description adds that it accepts multiple datetime formats (ISO 8601, Unix timestamps, natural strings) and returns converted time with UTC offset. 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?
Three sentences front-loaded with purpose, followed by accepted formats, return details, and an example. No unnecessary words; efficiently communicates essential information.
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 mentions the return format (converted time with UTC offset). It does not detail error handling (invalid timezone, malformed datetime), but for a simple tool, it is 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% with descriptions for each parameter. The description adds meaning: it explains valid formats for datetime and example usage, enriching beyond the schema's basic 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 the verb 'Convert' and the resource 'datetime from one IANA timezone to another'. It specifies accepted input formats and return information, distinguishing it from siblings (no other timezone conversion tool exists).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for timezone conversion but lacks explicit guidance on when not to use or alternatives. However, given no sibling timezone tools, the context is clear enough. Could mention that it's for IANA timezones only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
top_x402_sellersTop x402 sellers in the recent windowARead-onlyIdempotentInspect
List the x402 sellers earning the most USDC (or serving the most calls) on Base in the last ~24h, derived from on-chain USDC transfers. Cached snapshot — safe to call freely. Useful for agents discovering the live x402 economy: who's getting paid, which networks, and where to point demand. Defaults: top 10, sort by USDC, exclude this host's own wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Rank by USDC settled (default) or by call count | |
| limit | No | Max rows to return (default 10, max 50) | |
| include | No | 'external' (default) hides this host's own wallet; 'all' includes it |
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 that it is a cached snapshot (stale data possible), specifies default sorting and filtering, and explains the include parameter. 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 compact, with a clear purpose statement, followed by key usage notes in three sentences. No unnecessary words, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the result set (top sellers with earnings/calls) and data source (on-chain USDC transfers). It covers defaults and filtering, leaving little ambiguity for a list 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?
Input schema has 100% description coverage, but the description adds context: defaults for sort and limit, and explains that include='external' hides the host's wallet. This provides meaningful guidance beyond the enum labels.
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 lists top x402 sellers by USDC earned or call count, on Base in the last ~24h, derived from on-chain USDC transfers. It distinguishes itself from sibling tools like about_agent402 or call_tool by focusing on seller rankings.
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 notes it is a cached snapshot, safe to call freely, and useful for discovering the live x402 economy. It provides defaults but does not explicitly state when not to use or list alternatives, though context implies it is for discovery.
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] Convert a value between units of length, mass, temperature (C/F/K), data, time, or speed.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the '[free]' tag and lists supported categories, providing modest additional 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 a single, efficient sentence that includes the key fact of being free and the supported unit categories. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's essence and categories but lacks details on unit formats and return values. Without an output schema, the agent has incomplete context for reliable use.
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?
With 0% schema description coverage, the description must clarify parameters. It implies 'value' is a number, 'from' and 'to' are unit strings, but doesn't specify valid unit abbreviations or formats, leaving ambiguity for the agent.
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 from multiple categories (length, mass, temperature, data, time, speed), making the purpose specific and distinct from sibling tools like timezone-convert.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The '[free]' tag hints at cost but not usage context.
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!