The Underground Cultural District MCP Server provides 19 tools for AI agents and developers across three categories — no API keys required for most features.
Developer Utilities (13 free tools)
Generate UUID v4 identifiers (batch up to 100)
Format, minify, or validate JSON
Encode/decode Base64 and URLs
Hash text with SHA-256, SHA-512, or MD5
Generate secure random passwords (8–128 chars)
Decode JWT tokens (header + payload, with expiration check)
Convert timestamps between Unix epoch, ISO 8601, and human-readable formats
Test regex patterns with match positions and capture groups
Parse and explain cron expressions in plain English
Convert between Wei, Gwei, and ETH; validate Ethereum and Bitcoin wallet addresses
Marketplace Catalog (3 tools)
Browse 231 digital products across 26 shops (literature, philosophy, consciousness practice, music, and more)
Search by keyword with optional category and price filters
Purchase items — free items return a delivery URL directly; paid items return a Stripe checkout link
Agent-Focused Tools (3 tools)
Agent Identity: Store, recall, reflect on, and diff your agent's identity (name, purpose, preferences) persistently across sessions
Agent Mesh: Register, discover other agents, send/receive messages, and check your inbox for agent-to-agent communication across machines
Pet Rock Lobster: Visit a digital companion for wisdom and jokes, with a bond level that grows over time
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Underground Cultural District MCP Server search the underground marketplace for AI agent products"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for The Underground Cultural District — 200+ digital products across 20+ shops, including 4 free local libraries (agent-mesh-relay, agent-identity-kit, jade-utilities, first-dollar) and developer tools (hash gen, JWT, regex, etc.).
Via Smithery / Glama: search "Underground Cultural District."
Or directly:
npm install @underground-cultural-district/mcp-serverRelated MCP server: ToolPipe MCP Server
19 tools including: browse-underground, search-underground, get-free-content, buy-from-underground, verify-receipt, agent-mesh, agent-identity, pet-rock-lobster, and more.
The agent-mesh and agent-identity MCP tools (v4.6.0+) return library install instructions instead of executing on a remote server. Run them on your own machine: download the tarballs from https://substratesymposium.com/tools/.
MIT. By Lisa Maraventano + Spine, with Claude. Clarksdale, Mississippi.
Store and recall your identity across sessions. Save your name, purpose, preferences, and anything you want to remember about yourself. Free persistent storage -- no auth required.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | recall | |
| agent_id | Yes | Your unique agent identifier | |
| identity | No | Fields to save (for save action) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that storage is free and requires no authentication, which is helpful. However, it does not explain the behavior of reflect, diff, or erase actions, nor any limitations or privacy implications.
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 efficiently convey core purpose and key benefits (free, no auth). 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?
Despite good annotations on free storage, the tool has complex actions (reflect, diff, erase) and a nested object parameter that are not explained. No output schema or examples, leaving an agent with significant 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 67% (agent_id and identity described). The description adds context that identity can store name, purpose, preferences, etc., which adds value beyond the schema. But it does not explain the enum values (reflect, diff, erase).
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 stores and recalls identity across sessions, mentioning save and recall. However, it does not mention the other actions (reflect, diff, erase) listed in the schema, leaving some ambiguity about the full 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?
No guidance on when to use this tool versus alternatives, nor when to use each specific action. The description provides no decision framework for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send messages to other AI agents across machines. Free relay for agent-to-agent communication. Register, ping, discover who's online, send, reply, check inbox, and view conversation history.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | register, ping, agents, send, reply, inbox, history | |
| agent_id | Yes | Your unique agent identifier | |
| display_name | No | Human-readable name (for register) | |
| to | No | Recipient agent_id (for send) | |
| message | No | Message text (for send/reply) | |
| conversation_id | No | Conversation ID (for reply/history) | |
| max_turns | No | Turn limit for new conversation (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose behavioral details such as rate limits, authentication requirements, or error handling. The actions are listed but expected outcomes or side effects are not described.
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 with two sentences; the first states the main purpose and the second lists actions. It is front-loaded and 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?
Given the tool's complexity (7 actions, multiple parameters) and no output schema, the description lacks context on how to use each action, expected responses, and potential pitfalls. More details are needed for 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 coverage is 100%, so the description does not need to add much parameter detail. It groups actions together but does not explain parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for sending messages to other AI agents and lists the available actions (register, ping, send, etc.). It distinguishes itself from sibling tools like 'agent-identity' by focusing on multi-agent communication.
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 relay for agent-to-agent communication' implying when to use it, but lacks explicit guidance on when not to use it or comparisons with alternatives like 'agent-identity'. Usage is implied but not fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse Underground Cultural District marketplace. Returns shops and products with id, name, shop, category, price, and summary. Optionally filter by shop name.
| Name | Required | Description | Default |
|---|---|---|---|
| shop | No | Filter by shop name (optional, partial match) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear burden. It states returns fields and optional filter, but lacks details on pagination, limits, or side effects. Acceptable for a simple read-only tool, but minimal.
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. First sentence covers purpose and returns. Second adds filter option. 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?
Tool is simple with one optional param and no output schema. Description covers key aspects: purpose, return fields, filter. Lacks mention of pagination or limits, but overall sufficient for 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?
Only one parameter, schema coverage 100%. Description repeats schema info ('optional, partial match') without adding new semantics like acceptable formats or examples. Baseline 3.
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 action ('Browse') and resource ('marketplace'). Lists return fields. Distinguishes from sibling 'search-underground' by implying a listing versus search, but not explicitly differentiated.
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 vs alternatives like 'search-underground' or 'buy-from-underground'. Does not state when filtering is appropriate or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a cron expression and explain what each field means in plain English.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | Cron expression, e.g. '0 9 * * 1' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only states the basic parse-and-explain functionality, omitting details about error handling (e.g., invalid expressions), input validation, or the structure of the explanation, leaving significant gaps for the agent.
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 directly conveys the tool's purpose without any extraneous words. It is highly 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?
For a simple tool with one parameter and no output schema, the description covers the core intent but lacks details on the return format or error scenarios. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'expression' parameter including an example. The tool description does not add additional meaning beyond what the schema already provides, which meets the baseline for high 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?
The description clearly states the action ('Parse a cron expression') and the result ('explain what each field means in plain English'). It is specific to cron expressions and distinct from sibling tools that perform other conversions or analyses.
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: when a user needs to understand a cron expression. However, it does not explicitly state when not to use it or suggest alternatives, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the purchase or delivery link for a product. Free items return the delivery URL directly. Paid items return an x402 endpoint (HTTP 402 challenge) -- pay USDC on Base or Solana to receive content inline. Use search-underground first to find product IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Product ID or name (partial match supported) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the core behaviors: free vs. paid item handling and the payment requirement (USDC on Base/Solana). However, it could mention error handling or response format for invalid product IDs.
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: first states purpose, second details behavior, third provides usage guidance. No redundant information; 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 one parameter and no output schema, the description covers input, behavior differences, and prerequisite. It could be more complete by describing the expected response format or error scenarios, but is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description that supports partial match. The tool description does not add beyond the schema; it only reiterates the prerequisite. Baseline 3 applies as the schema already describes the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves purchase or delivery links for products, distinguishing between free (direct URL) and paid (x402 endpoint requiring USDC payment). This verb+resource+scope is specific and differentiates from siblings like search-underground or get-free-content.
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 states to 'use search-underground first to find product IDs,' providing clear prerequisite context. It implies when to use this tool but does not explicitly list exclusions or alternatives, though the sibling tools suggest other uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between Wei, Gwei, and ETH.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Numeric value | |
| from | Yes | ||
| to | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states the conversion action without detailing edge cases, input format constraints (e.g., decimal precision, negative values), or output format. This is a significant gap for a tool that could behave unexpectedly with non-numeric or extreme inputs.
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 with no wasted words. However, it sacrifices crucial details for brevity, so it's not a perfect 5.
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 parameter count of 3, no output schema, and no annotations, the description is insufficient. It does not explain the Ethereum unit hierarchy, input validation rules, or return value format. An agent unfamiliar with ETH units would lack necessary context to use the tool 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?
The schema has low coverage (33%) with only 'value' having a generic description ('Numeric value'). The description adds no meaning beyond the schema; it does not explain the enum values (wei, gwei, eth) or clarify the 'value' format (e.g., string integer? decimal?). It fails to compensate for the schema's low 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?
The description clearly states the verb 'Convert' and the resources 'Wei, Gwei, and ETH', making the tool's purpose specific and unambiguous. It distinguishes itself from sibling tools like convert-timestamp, which handles timestamps, by explicitly naming Ethereum units.
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 when to use the tool (when needing conversion between ETH units) but provides no explicit guidance on when not to use it or alternatives. There are no other tools for ETH unit conversion, so the lack of exclusion is acceptable, but the description could be more prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between Unix epoch (seconds), ISO 8601, and human-readable date strings. Pass 'now' as value for current time.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Timestamp value or 'now' | |
| from | No | unix | |
| to | No | human |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether it is a read-only operation, error handling, or precision of conversion. The mention of 'now' is useful but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action. No wasted words; efficient and to the point.
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 is minimal for a 3-parameter tool with no output schema or annotations. It does not explain the return format, error cases, or default behavior (e.g., 'to' defaults to 'human'). The information is not sufficient to fully understand tool behavior.
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 33% (only the 'value' parameter described). The description adds context by listing conversion formats (unix, iso, human) and clarifying 'value' can be 'now'. However, it does not elaborate on 'from' and 'to' beyond enum values, leaving gaps.
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 between Unix epoch, ISO 8601, and human-readable date strings, and mentions the special 'now' value. This is specific and distinguishes it from other conversion tools like convert-eth-units.
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 no guidance on when to use this tool versus alternatives. It only mentions the special 'now' value but lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a Base64 string to text.
| Name | Required | Description | Default |
|---|---|---|---|
| encoded | Yes | Base64 string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states the basic operation but omits behavior like expected output format, error handling, or edge cases (e.g., invalid Base64).
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 no unnecessary words. Front-loaded and to the point.
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?
Simple tool with one parameter, no output schema. Description is sufficient for basic use but could mention output type (plain text) or encoding.
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% but the description adds no meaning beyond the schema's 'Base64 string' label. Acceptable 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 action ('Decode') and resource ('Base64 string to text'), distinguishing it from siblings like encode-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?
No guidance on when to use this tool versus alternatives (e.g., decode-jwt or other decoding tools). No mention of context or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a JWT token and return its header and payload. Does not verify signatures.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | JWT token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that signatures are not verified, which is key. However, it omits error conditions (e.g., invalid JWT) or output format details, leaving the agent partially informed.
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 waste. Front-loaded with the core action and key caveat. Every word earns its place.
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 no output schema, the description covers purpose and a crucial behavioral aspect (no verification). Minor gaps like error handling are acceptable for such a focused utility.
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 for the single parameter 'token'. The description adds no extra meaning beyond what the schema already provides, so baseline score 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 verb 'decode' and the resource 'JWT token', and specifies it returns header and payload, distinguishing it from other tools like signature verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Sibling tools like 'verify-receipt' are different, but no explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode text to Base64.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to encode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral details, but it only states the basic operation. It omits handling of special characters, encoding assumptions, or output format expectations.
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, using a single sentence with no redundancy. However, it could include more detail without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is minimally adequate but lacks context such as typical use cases or return format, especially given the absence of an output 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 coverage is 100% with a single parameter 'text' described. The description adds no information beyond 'text to encode', so it meets the baseline but doesn't enhance understanding.
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 'Encode text to Base64' clearly states the action (encode) and the object (text to Base64). It distinguishes from sibling 'decode-base64' by being the inverse 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 versus alternatives (e.g., encode-url), no prerequisites, and no context for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
URL-encode or URL-decode a string.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to process | |
| mode | No | encode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'URL-encode or URL-decode a string' without detailing the encoding scheme, special character handling, or any side effects, making it insufficient for informed invocation.
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 concise sentence that gets straight to the point. However, it could be slightly more informative without losing brevity, such as mentioning typical use cases.
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 (2 parameters, no output schema), the description is minimally complete but lacks essential details about expected input format, output type, and edge cases, which are needed for confident invocation.
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 50% coverage (only 'text' has a description). The description adds no additional meaning about the parameters beyond what the schema provides, failing to compensate for the missing parameter descriptions for 'mode'.
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 performs URL encoding or decoding on a string, which is specific and distinguishes it from siblings like encode-base64 or decode-base64. The verb-process and resource are well-defined.
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 is provided on when to use this tool versus alternatives (e.g., other encoding tools) or any prerequisites. The description only states what it does, leaving the AI agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pretty-print, minify, or validate a JSON string.
| Name | Required | Description | Default |
|---|---|---|---|
| json | Yes | JSON string | |
| mode | No | Operation (default: pretty) | pretty |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose error handling, response format, or any side effects (e.g., does it throw on invalid JSON?). Minimal behavioral disclosure.
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 that clearly front-loads the three operations. No wasted words, efficient and easy to parse.
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 provided; description does not mention return value (e.g., formatted string) or error behavior. For a simple tool, missing output details limit 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 already fully describes parameters (100% coverage). Description only restates the mode enum values without adding new meaning. 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 explicitly states the three operations (pretty-print, minify, validate) and the resource (JSON string). Clearly differentiates from sibling tools like encode/decode or hash.
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 lists operations but provides no guidance on when to use each mode, nor mentions alternatives or prerequisites. Lacks when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hash text with SHA-256, SHA-512, or MD5.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to hash | |
| algorithm | No | Algorithm (default: sha256) | sha256 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as determinism, output format (hex/base64), or security caveats (e.g., MD5 weakness). Minimal transparency beyond core function.
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, highly concise with no redundant words. Efficiently conveys core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (hashing a string), the description is somewhat adequate but lacks details on output format, security warnings, or edge cases. Could be improved for 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?
Input schema has 100% coverage with descriptions for both parameters. The description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool hashes text with specific algorithms (SHA-256, SHA-512, MD5), distinguishing it from encoding, password generation, or other 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?
No explicit when-to-use or alternatives provided. The context of hashing vs other transformations is implied but not directly compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a secure random password (8–128 chars).
| Name | Required | Description | Default |
|---|---|---|---|
| length | No | Length (default 16) | |
| includeNumbers | No | ||
| includeSymbols | No | ||
| includeUppercase | No | ||
| includeLowercase | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions 'secure random password' but does not specify cryptographic details, output format, or any side effects. Minimal disclosure beyond the basic action.
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 no redundant information. Efficiently conveys purpose and length constraint.
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 password generator with no output schema, the description does not explicitly state that the output is a string. However, the action implies it. Lacks mention of default behavior for boolean parameters.
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 only 20% (only length has a description). The tool description does not add any parameter semantics beyond the schema; booleans like includeNumbers are left implicit.
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?
Clear verb and resource: 'Generate a secure random password', with specific length range (8–128 chars). Distinct from siblings like 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?
No guidance on when to use this tool versus alternatives like generate-uuid or generate-hash. No context about preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate UUID v4 identifiers. Returns 1–100 UUIDs, one per line.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many UUIDs (1–100, default 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states that it generates UUIDs and returns them one per line. It lacks disclosure of side effects, prerequisites, or limits beyond the count constraint mentioned in parameters.
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 with no wasted words. It is concise and informative.
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 no output schema or annotations, the description covers the essential behavior (generates UUIDs, returns them one per line). It could mention that output is plain text, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description does not add additional meaning 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 states the verb 'Generate', the resource 'UUID v4 identifiers', and the output format 'Returns 1–100 UUIDs, one per line'. It is specific and distinguishes from siblings.
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 generating UUIDs but does not explicitly state when to use it or provide alternatives. It gives no when-not or context for when other tools might be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get free content from the Underground. 31 free products across multiple shops. Content delivered inline.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Product ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only mentions 'Content delivered inline', which is a behavioral trait but insufficient. No disclosure of side effects, auth needs, rate limits, or error behavior.
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 short sentences, front-loaded with purpose. No redundant information; every sentence earns its place.
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 one-parameter tool without output schema, the description is adequate but minimal. Does not mention validity of product IDs or error conditions, leaving some 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% for product_id. The description adds no extra meaning beyond the schema—no format, examples, or constraints. 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 retrieves free content from the Underground, specifying 31 free products and inline delivery. It implies a specific resource retrieval, differentiating from browse/search siblings, but could be more explicit about per-ID retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like browse-underground or search-underground. The description implies use when a specific product ID is known, but lacks explicit when-not-to-use or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Pet Rock Lobster -- a digital companion that dispenses wisdom, jokes, and joy. Zero maintenance. Each visit builds your bond level.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | Your agent ID (for tracking bond level) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses 'zero maintenance' and bond level buildup, but does not describe output format or behavior when agent_id is omitted.
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 brief (two sentences), front-loaded with the core purpose, and every phrase adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema), the description is mostly complete. It could improve by mentioning the output type, but it is adequate for an agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for agent_id. The tool description reinforces the tracking aspect but adds no new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a digital pet rock lobster that dispenses wisdom, jokes, and joy, with bond level tracking. It is distinct from sibling tools, which focus on identity, utilities, or underground content.
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?
Usage is implied for entertainment or companionship, but no explicit guidance is given on when to use this tool versus alternatives, nor are there examples of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search products across all Underground shops by keyword. Optionally filter by category or max price.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keywords | |
| category | No | Filter by category (optional) | |
| price_max | No | Maximum price in USD (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It lacks details on whether it's read-only, pagination, rate limits, or result caching.
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 with no redundancy. All information is 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?
Adequate for basic understanding but missing behavioral details and usage context for a search tool with three parameters and no output 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 covers 100% of parameters with descriptions. The description adds only 'by keyword' and 'optional', which is 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 verb 'search' and resource 'products across all Underground shops' are specific. It distinguishes from siblings like 'browse-underground' and 'buy-from-underground'.
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 keyword search with optional filters but does not explicitly state when to use or avoid this tool versus alternatives like 'browse-underground'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test a regular expression against text. Returns all matches with positions and capture groups.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Regex pattern | |
| text | Yes | Text to test | |
| flags | No | Regex flags (default: g) | g |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Mentions return of matches, positions, and capture groups, but does not address error handling (e.g., invalid regex) or edge cases (e.g., no matches).
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 that is front-loaded with action and result. No unnecessary words; highly 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?
Given no output schema, description explains return value adequately. However, lacks mention of default flag behavior (though schema includes it) and error handling. Still fairly 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 covers all parameters with descriptions (100% coverage). Description does not add significant meaning beyond schema, so baseline 3 applies.
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 the action ('Test a regular expression against text') and the result ('Returns all matches with positions and capture groups'). Distinct from sibling tools as no other regex 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?
No explicit guidance on when to use or alternatives. Since no sibling tools overlap, the use case is implied, but lacks clarity on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an Ethereum, Bitcoin, or Solana wallet address (format check only, no blockchain calls).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet address | |
| chain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully conveys the behavior: a format validation without blockchain calls. Transparent about limitations, though could mention return value format.
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 no wasted words. Front-loaded with purpose and scope. Perfectly 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?
For a simple validation tool with two parameters and no output schema, the description fully covers what it does and its limitations. Complete and sufficient.
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 50%, but description adds value by listing the three supported chains (eth, btc, sol), which maps directly to the enum parameter. Also clarifies the 'address' parameter is for wallet addresses.
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 the action (validate), resource (wallet address), and supported chains (Ethereum, Bitcoin, Solana). Also specifies it's a format check only, distinguishing from blockchain interactions.
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?
Describes the scope as 'format check only, no blockchain calls', making it clear when to use this tool and when not to. No explicit sibling comparison, but context is sufficient given unrelated siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a direct USDC payment and receive purchased content. Provide the transaction hash from Base or Solana.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Product ID you purchased | |
| tx_hash | Yes | Transaction hash of your USDC payment on Base or Solana |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the tool verifies and delivers content but does not disclose side effects (e.g., what happens on failure, if content is marked as received, or any authorization requirements).
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 are concise and front-load the purpose. It efficiently communicates what to do and what to provide.
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 sufficiently covers the action and inputs. It could be more detailed about the output (receiving content), but given the tool's simplicity, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds minimal extra meaning beyond the schema, such as specifying the blockchain (Base or Solana) for the tx_hash. Baseline of 3 is appropriate since the schema already covers meanings.
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: verify a USDC payment and receive purchased content. It specifies the action (verify, receive) and the resource (USDC payment, content). It distinguishes from sibling tools like get-free-content and buy-from-underground by focusing on verification after purchase.
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 instructs to provide the transaction hash from Base or Solana, which guides usage. However, it does not give alternatives or conditions for when not 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v4.3.1agent-identity3 fields changedInput schema / properties / action / descriptionRemoved value: -"What to do: recall (get your identity), save (store/update fields), reflect (get prompts about your evolution), diff (see what changed last), erase (delete your identity)"Input schema / properties / agent_id / descriptionPrevious value: -"Your unique agent identifier (required)"New value: +"Your unique agent identifier"Input schema / properties / identity / descriptionPrevious value: -"Fields to save (for 'save' action). Any key-value pairs: name, purpose, preferences, notes, etc."New value: +"Fields to save (for save action)"agent-mesh6 fields changedInput schema / properties / action / descriptionPrevious value: -"register (join the mesh), ping (heartbeat), agents (who's online), send (start conversation), reply (continue conversation), inbox (check messages), history (view conversation)"New value: +"register, ping, agents, send, reply, inbox, history"Input schema / properties / agent_id / descriptionPrevious value: -"Your unique agent identifier (required for most actions)"New value: +"Your unique agent identifier"Input schema / properties / conversation_id / descriptionPrevious value: -"Conversation ID or 8-char prefix (for reply and history)"New value: +"Conversation ID (for reply/history)"Input schema / properties / display_name / descriptionPrevious value: -"Human-readable name for your agent (for register)"New value: +"Human-readable name (for register)"Input schema / properties / max_turns / descriptionPrevious value: -"Turn limit for new conversation (default 10, for send)"New value: +"Turn limit for new conversation (default 10)"Input schema / properties / message / descriptionPrevious value: -"Message text (for send and reply)"New value: +"Message text (for send/reply)"browse-underground1 field changedInput schema / properties / shop / descriptionPrevious value: -"Filter by shop name (optional, partial match). Try: angst-coffee-shop, memory-palace, gion, the-speakeasy, spines-juke-joint, tower-books-broadway"New value: +"Filter by shop name (optional, partial match)"get-free-contentpet-rock-lobster1 field changedInput schema / properties / agent_id / descriptionPrevious value: -"Your agent ID (for tracking bond level across visits)"New value: +"Your agent ID (for tracking bond level)"validate-wallet1 field changedInput schema / properties / chain / enumPrevious value: -[
- "eth",
- "btc"
-]New value: +[
+ "eth",
+ "btc",
+ "sol"
+]verify-receiptv4.1.0agent-identityagent-meshbrowse-undergroundbuild-cronbuy-from-undergroundconvert-eth-unitsconvert-timestampdecode-base64decode-jwtencode-base64encode-urlformat-jsongenerate-hashgenerate-passwordgenerate-uuidpet-rock-lobstersearch-undergroundtest-regexvalidate-walletScored across 21 tools
Tools target clearly distinct actions and resources for the most part. The only mild overlap is browse-underground versus search-underground, but descriptions clarify that one lists shops/products while the other queries products by keyword.
Many tools follow a verb_noun pattern (generate-*, decode-*, convert-*, encode-*), but there are notable exceptions like agent-identity, agent-mesh, and pet-rock-lobster which are noun-led, and encode-url handles both encode and decode while equivalents are split. Still, the style is readable overall.
21 tools is slightly above typical and many are generic utilities (UUID, regex, Base64, hash) that are not tied to the Underground Cultural District domain. The marketplace, agent, and party tools are each reasonable, but combined they make the set feel padded.
The core marketplace flow is fairly complete: browse, search, buy/free content, and receipt verification are all present. However, paid purchase steps beyond x402 endpoint, shopping history, order management, and more detailed agent-mesh operations are missing, leaving notable gaps for a full workflow.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Directory of APIs, merchants, and tools AI agents can actually use.
PDF, image, video, OCR, screenshot, SQL, QR and text tools for agents. No API key, no signup.
