List the on-chain AI agent marketplace: every service with its x402 per-call price, provider, calls and volume.
| Name | Required | Description | Default |
|---|---|---|---|
| capability | No | Optional capability filter, e.g. pricing, audit, market-data |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits such as read-only nature, potential side effects, or data source. Since there are no annotations to supplement, the description carries the full burden and fails to mention whether this operation modifies state or is purely informational.
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 directly conveys the tool's function. It avoids unnecessary detail and is well-structured for quick 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?
Given the simple one-parameter, no-output-schema nature, the description provides adequate context about what the tool returns (a list of services with key attributes). It could be slightly more complete by hinting at the response format, but it is sufficiently informative for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'capability' is fully described in the schema with a clear example list, achieving 100% coverage. The tool description itself adds no additional meaning beyond the schema, so it meets the baseline but does not exceed it.
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 the on-chain AI agent marketplace with service details like x402 price, provider, calls, and volume. However, it does not differentiate this tool from closely named siblings such as aman_market or aman_service_catalog, which could lead to confusion about the unique 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 explicit guidance is provided on when to use this tool versus alternatives like aman_service_catalog or aman_market. The description is purely declarative and does not mention any context or selection criteria beyond the inherent listing action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
aman_list_services and aman_service_catalog both describe the same x402 service marketplace with overlapping fields, and aman_market overlaps heavily with aman_price. The detailed descriptions help separate them, but an agent could easily select the wrong tool for the same task.
All tools share the aman_ prefix and use lowercase with underscores, but the pattern is mixed: noun phrases like aman_market, aman_price, and aman_chain_info sit alongside verb_noun tools like aman_get_tx, aman_list_services, and aman_invoke_service. It is readable but not a single consistent convention.
11 tools is well within the typical 3-15 range and the set spans chain info, transactions, tokens, market data, and agent services. However, a couple of near-duplicate tools such as list_services/service_catalog and market/price make the count feel slightly padded.
The core domain is well covered: chain status, transaction lookup, token details, market snapshots, service discovery, and paid agent invocation are all present. Minor gaps like account balance lookups or block-by-height queries are not blockers for the apparent read-only/explorer purpose.