MCP server exposing T54 XRPL x402 seller SKUs (OpenAPI) as tools: structured query, research brief, commerce data, and related routes. HTTP 402 + x402 settlement via broker (XRPL / Base USDC per env). Unified HTTPS host with health at /health.
The tools split into contract security (audit, monitor, triage) and marketplace API (t54_*) categories, each with distinct purposes. However, t54_x402_request is a generic executor that could overlap with specific t54_* tools, though the description advises preferring per-operation tools when available. Overall, most tools are clearly differentiated.
Two naming conventions exist: contract_* (verb_noun, snake_case) and t54_* (prefix with varying patterns like t54_get_health, t54_hello_ping, t54_agent_commerce_data). The lack of a unified prefix or consistent verb/noun ordering across all tools lowers consistency significantly.
With 12 tools, the server covers both contract security and marketplace operations without being overwhelming. Each tool serves a distinct role, and the count is appropriate for a specialized marketplace with auxiliary security features.
The contract tools provide auditing, monitoring, and triage—core lifecycle coverage. The marketplace tools include health, listing, and specific data endpoints. Minor gaps exist (e.g., no unsubscribe for monitoring, no user account management), but the overall surface is well-matched to the server's stated purpose.
Run a full 5-phase security audit on up to 3 EVM contract addresses. Handles EIP-1167 proxy/implementation pairs. Returns complete intelligence card including Slither findings, Echidna fuzz results, deployer profiling, EIP-7702 delegate detection, money flow trace, and holder analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | No | CAIP-2 chain id (default Base mainnet eip155:8453) | eip155:8453 |
| addresses | Yes | Comma-separated 0x addresses (max 3 proxy/implementation pairs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, but the description does not disclose any side effects or state changes. It lists analysis capabilities but omits whether results are stored, if external APIs are called, or any limitations. The idempotentHint=true and destructiveHint=false provide some safety context, but the description adds no additional behavioral caveats.
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 the core action, and uses a compact enumeration of outputs without extraneous words. 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 complex tool with no output schema, the description covers input constraints and provides a detailed list of return data. It doesn't mention execution time, prerequisites, or failure scenarios, but the enumerated outputs give a solid understanding of expected results.
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 description clarifies that 'addresses' accepts up to 3 EVM addresses and specifically handles proxy/implementation pairs, supplementing the schema. The chain_id parameter is well-described in the schema, and the description's mention of EVM and Base helps contextualize 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 it runs a full 5-phase security audit on up to 3 EVM addresses, distinguishing it from lighter sibling audit tools. It also enumerates specific output components, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the tool as a 'full' audit that handles EIP-1167 proxy pairs, indicating it is intended for comprehensive security reviews. It lacks explicit when-not-to-use or alternative tool mentions, but the context is clear enough for an agent to infer appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe to 30-day continuous monitoring of up to 10 EVM contract addresses. Fires webhook alerts on admin key movement, liquidity drops, claim condition changes, or new critical Slither findings.
| Name | Required | Description | Default |
|---|---|---|---|
| addresses | Yes | Up to 10 0x-prefixed EVM addresses to watch | |
| thresholds | No | Optional JSON object for alert sensitivity (e.g. liquidity drop %, admin key moves). Omit or {} for seller defaults. | |
| webhook_url | Yes | HTTPS URL that receives POST alerts when risk thresholds breach | |
| duration_days | No | Subscription length in days (default 30; max per seller policy). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given annotations already set readOnly=false and idempotent=true, the description adds useful behavior: 30-day duration, webhook firing on specific risk events, and a maximum of 10 addresses. It avoids contradiction and fills in the 'side effect' of creating an active subscription.
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 lean sentences with no filler. The action, constraints, and alert categories are all front-loaded or directly contextual.
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?
With a complete schema and these two sentences, an agent knows what action to take and effect to expect. But the tool lacks an output schema and the description does not explain the response shape, how repeated subscriptions are handled, or any payment/cancellation details.
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 coverage is 100%, so baseline is 3. The description repeats the address limit already in the schema and only loosely trades thresholds to alert types. It does not add meaningful parameter semantics beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Subscribe to') and names a precise resource: 30-day continuous monitoring of up to 10 EVM contract addresses. It lists concrete alert categories and clearly distinguishes this from one-time audit/triage 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?
Usage context is implied: the subscription product and alert categories suggest this is for continuous monitoring, not one-off analysis. However, it does explicitly say when to use this vs alternatives or 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.
Screen an EVM smart contract address for malicious patterns, honeypots, rug mechanics, and known scam frameworks. Returns risk score (0-100), verdict (SAFE/SUSPICIOUS/MALICIOUS), and top threat flags. Completes in under 30 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | No | CAIP-2 chain id (default Base mainnet eip155:8453) | eip155:8453 |
| contract_address | Yes | 0x-prefixed EVM contract address to screen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, and the description adds value by detailing the return contract (risk score 0-100, verdict SAFE/SUSPICIOUS/MALICIOUS, top threat flags) and a performance guarantee (<30s). It does not disclose whether external network calls or stored state are involved, but it does not contradict 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?
Two sentences deliver the action, threat scope, output format, and latency with zero filler. Every phrase contributes information, making it easy to scan and process.
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?
With no output schema, the description compensates by explicitly listing the return values, and it names the EVM scope and default chain through the schema. However, it does not clarify how verdict thresholds are derived or how to interpret the risk score, which is a minor gap for a security-oriented 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 description coverage is 100%: contract_address is already described as '0x-prefixed EVM contract address to screen' and chain_id as a CAIP-2 chain id with a Base mainnet default. The tool description adds no additional parameter-level context, so it stays at the baseline for high 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?
The description opens with a specific verb-resource pair: 'Screen an EVM smart contract address,' and enumerates concrete threat categories (malicious patterns, honeypots, rug mechanics, and known scam frameworks). It closes with clear outputs (risk score, verdict, threat flags) and a time bound that distinguishes it from deeper audit or monitoring tools in its sibling 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?
The phrase 'Completes in under 30 seconds' and the word 'triage' imply a quick pre-screening use case, but the description never explicitly states when to use this tool versus contract_audit or contract_monitor_subscribe, nor does it mention any exclusions. The guidance is present only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifiable swarm proof + x402 commerce bundle (premium)
HTTP GET /x402/v1/agent-commerce-data (operationId agentCommerceData). Paid routes may return HTTP 402 until the x402 broker settles on the configured rail.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Payload size — standard (smaller bundle) or full (more evidence rows). | standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by disclosing the HTTP 402 behavior for unpaid routes. However, it does not clarify why readOnlyHint is false, what side effects may occur, or what happens after payment settles. Annotations already cover idempotency and non-destructiveness.
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 short but redundant, repeating the title verbatim. The endpoint and operationId are useful for technical reference but not essential for an AI agent's selection. It could be more streamlined.
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 premium/payment aspect and the existence of sibling t54_x402_request, the description is incomplete. It does not explain the relationship between the tools, what to do upon receiving a 402 response, or what the returned bundle contains. Without an output schema, the description should compensate but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the depth parameter is fully described (enum, default, and description). The description does not add any meaning beyond the schema, such as how to choose between standard and full payloads.
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 identifies the resource as a 'verifiable swarm proof + x402 commerce bundle' and mentions HTTP GET, but lacks an explicit action verb like 'retrieves' or 'fetches'. It does not clearly differentiate from sibling t54_x402_request, which likely handles the payment flow.
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 such as t54_x402_request, nor any prerequisites like payment. The 402 note hints at a payment dependency but does not explain how to use the tool in that flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Airdrop / incentive screening (Farm Score, risk flags)
HTTP GET /x402/v1/airdrop-intelligence (operationId airdropIntelligence). Paid routes may return HTTP 402 until the x402 broker settles on the configured rail.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Airdrop or incentive topic to score (Farm Score, narrative screening). | |
| context_note | No | Optional free-text context or links for the screening report (max 4000 chars). | |
| contract_address | No | Optional EVM contract on Base for Tier-1 triage merge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-destructive, open-world, and idempotent behavior. The description adds valuable behavioral context about paid routes potentially returning HTTP 402 until the x402 broker settles, and explicitly identifies the HTTP GET method. This goes beyond annotation-only information and helps the agent anticipate payment-related errors.
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 and front-loaded with the core purpose, but the first sentence is a verbatim repetition of the title, which is slightly redundant. Still, the two sentences are efficient and avoid unnecessary fluff, earning a high conciseness score.
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?
Since there is no output schema, the description must clarify what the tool returns, but it only mentions 'Farm Score, risk flags' without elaborating on the report format or content. It also lacks context on how the screening works or how it differs from sibling tools. The payment detail is useful but does not compensate for the incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters with 100% coverage (topic, context_note, contract_address). The description does not add further semantic detail beyond what the schema provides, so the 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 'Airdrop / incentive screening (Farm Score, risk flags)' and provides the HTTP endpoint and operation ID, making the tool's purpose specific and distinct from general audit/research tools. However, it does not explicitly contrast it with sibling tools, though the unique focus on airdrops/incentives differentiates it.
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 just repeats the title and gives endpoint/payment details, with no mention of appropriate scenarios, prerequisites, or exclusions. The agent is left to infer usage from the title alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Heuristic constitution / ethics review
HTTP GET /x402/v1/constitution-audit (operationId constitutionAuditLite). Paid routes may return HTTP 402 until the x402 broker settles on the configured rail.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt_snippet | No | Text or agent instruction excerpt to screen for constitution / ethics heuristics (max 4000 chars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral detail that paid routes may return HTTP 402 until the x402 broker settles, which complements the annotations (idempotent, non-destructive). However, it does not explain whether the tool has side effects (readOnlyHint is false) or what the response contains. Since annotations already cover safety profile, this extra context earns a mid score.
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 and front-loaded with the title, then the endpoint and payment note. However, the first sentence is redundant with the title, and the payment note, while relevant, is tangential to purpose. Minimal waste but repetition keeps it from a top score.
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 with no output schema, the description still fails to mention what the response looks like or what 'audit' means operationally (e.g., heuristic pass/fail, scores, citations). The HTTP/402 note is niche and doesn't round out the tool's behavior, making the description incomplete for an agent deciding to invoke it.
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 fully describes the single parameter prompt_snippet with its purpose and max length, so the schema carries the semantic load. The description adds no parameter-specific details, but with 100% coverage the baseline of 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?
The description repeats the title 'Heuristic constitution / ethics review' and adds the HTTP endpoint and operationId, but does not explicitly state what action it performs (e.g., screens a prompt for violations) or what it returns. It is distinguishable from sibling tools like contract_audit by the 'constitution/ethics' domain, but the verb/resource combination is vague.
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 such as contract_audit or contract_triage. The only practical note is the payment/402 behavior, which addresses failure conditions, not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Seller health and LLM probe
Returns JSON including llm probe; does not require payment.
HTTP GET /health (operationId getHealth). Paid routes may return HTTP 402 until the x402 broker settles on the configured rail.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag idempotent and non-destructive, and the description adds useful context: the HTTP method, the free nature of the route, and the behavior of paid routes (402). It does not contradict annotations and provides enough extra detail to understand what the tool does beyond the structured fields.
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 three sentences long with no fluff: it states the title, return type, and key behavioral notes. Every sentence adds value (purpose, free status, HTTP method/path, 402 warning), making it appropriately concise and 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?
For a health-check tool with no input schema and no output schema, the description covers the essential aspects: endpoint, HTTP method, return type, and payment requirements. It does not detail the exact structure of the health response, but the information provided is sufficient for an agent to select and invoke the tool correctly in most contexts.
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 tool has zero parameters, so the description carries no parameter documentation burden. The baseline for no parameters is 4, and the description appropriately focuses on the return value and endpoint rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns JSON including an `llm` probe and specifies the HTTP GET `/health` endpoint. This distinguishes it from siblings like t54_hello_ping by explicitly mentioning the LLM probe and the HTTP path, making the tool's specific function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides contextual guidance by noting that the route 'does not require payment' and that paid routes may return HTTP 402 until the broker settles, implying this is a low-cost health check. However, it does not explicitly state when to use this tool versus alternatives like t54_hello_ping or list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Micropayment ping (cheapest SKU)
Confirms HTTP 402 + T54 facilitator path; minimal JSON body.
HTTP GET /hello (operationId helloPing). Paid routes may return HTTP 402 until the x402 broker settles on the configured rail.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover idempotency and destructive safety, but the description adds concrete behavioral context: the exact HTTP method and path, the operationId, the minimal JSON body, and the possibility of HTTP 402 until the broker settles. This goes beyond the annotations without contradicting them.
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 very short and front-loaded, but the first sentence 'Micropayment ping (cheapest SKU)' is a direct repetition of the title and does not add new information. The remaining sentences are efficient and informative, but the redundancy prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description covers the essential contract: endpoint, operationId, and the 402 behavior. It does not detail the exact success response body, but 'minimal JSON body' plus the annotations provide enough context for a competent agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to elaborate on beyond the input schema. The description reasonably omits parameter details and instead focuses on the endpoint and behavior, which is sufficient for a no-argument tool.
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 this tool is a micropayment ping confirming the HTTP 402 and T54 facilitator path, with a specific endpoint (HTTP GET /hello) and operationId. It is more specific than a generic ping and hints at differentiation via 'cheapest SKU', though it does not explicitly contrast with sibling tools like t54_get_health.
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 statement that paid routes may return HTTP 402 until the x402 broker settles implies this tool is useful for verifying the payment path before using paid routes. However, it does not explicitly state when to use this tool versus alternatives such as t54_x402_request or t54_get_health.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns operationIds, HTTP methods, paths, and query parameter names from the bundled OpenAPI spec (no network). Use before t54_x402_request or per-SKU tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar for additional transparency is lower. The description adds valuable context beyond annotations: it is offline ('no network') and enumerates the specific return fields, helping the agent anticipate output despite no output schema. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states exact output and data source, the second gives usage context. Every word is purposeful, no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool, the description plus annotations fully cover purpose, usage, and expected behavior. The explicit mention of t54_x402_request provides clear integration context, making the tool's role in the larger workflow obvious.
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 tool has zero parameters, so schema coverage is trivially 100%. With no parameters, the description has no parameter semantics to add, and the baseline for zero-param tools is 4.
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 precisely states the tool returns operationIds, HTTP methods, paths, and query parameter names from the bundled OpenAPI spec. It distinguishes itself from sibling tools by explicitly framing this as a pre-request discovery tool and notes the offline nature ('no network'), which sets clear expectations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use before t54_x402_request or per-SKU tools.' This tells the agent exactly when to invoke this tool relative to alternatives, giving clear sequencing and context for its role in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-section research brief
HTTP GET /x402/v1/research-brief (operationId researchBrief). Paid routes may return HTTP 402 until the x402 broker settles on the configured rail.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Subject line for the multi-section research brief (max 256 chars). | |
| context_note | No | Optional extra context, URLs, or constraints for the brief (max 2000 chars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the HTTP 402 payment behavior and endpoint details, which are useful beyond the annotations. Annotations already indicate idempotent, non-destructive, and non-read-only, and the description does not contradict them. However, it does not disclose what the tool returns or any side effects, so transparency is limited.
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 short but starts with a redundant restatement of the title. The useful endpoint and payment information is buried after the redundant first line. It is not waste-free, but it is compact.
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?
With no output schema, the description should explain what the tool returns, but it only mentions the HTTP endpoint and payment behavior. The purpose is implied by the title and parameter descriptions, but the description leaves the agent uncertain about the actual output format or structure of the 'multi-section research brief'. This is incomplete for a tool with 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?
The input schema provides 100% coverage with descriptions for both 'topic' and 'context_note', so the description need not add param details. It does not add any additional meaning beyond the schema, matching the baseline of 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?
The description repeats the title 'Multi-section research brief' without an explicit verb or action. It provides the HTTP GET endpoint and operationId, but does not state what the tool does (e.g., generates/retrieves a research brief) in actionable terms. This fails to distinguish it from sibling tools like t54_structured_query or t54_agent_commerce_data.
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 given on when to use this tool vs alternatives. The only conditional note is about HTTP 402 payments, which is a prerequisite/error condition, not a use-case guideline. There is no mention of competing tools or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Constitution-safe short LLM answer
Listing-friendly GET with q query parameter.
HTTP GET /x402/v1/query (operationId structuredQuery). Paid routes may return HTTP 402 until the x402 broker settles on the configured rail.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Natural-language question for a short constitution-safe answer (max 512 chars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate idempotent and non-destructive behavior. The description adds beyond that by specifying the HTTP GET method, the listing-friendly nature, and the paid-route behavior that may return HTTP 402 until the x402 broker settles. This is valuable context consistent with the `readOnlyHint: false` annotation, though it could disclose more about auth or rate limits.
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 and front-loaded with the endpoint and method. The only minor flaw is that the opening sentence repeats the title verbatim, adding little value, but otherwise every sentence contributes useful 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?
For a simple single-parameter GET tool with no output schema, the description covers the route, method, payment-related behavior, and the nature of the answer. It does not spell out the exact response payload, but the title and parameter description provide enough for an agent to invoke 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 100% coverage for the single parameter `q`, including a descriptive explanation and a max length. The tool description adds no semantic detail beyond what the schema already provides, so the 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 identifies a GET endpoint that accepts a natural-language `q` parameter and returns a short, constitution-safe LLM answer. It includes the route, operationId, and enough context to distinguish it from sibling tools like `t54_research_brief` or `t54_constitution_audit_lite`, though it lacks an explicit verb such as 'retrieves' or 'returns'.
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 explicit guidance on when to use this tool versus alternatives. It mentions 'listing-friendly' and a payment/402 caveat, but does not state when to prefer this over related tools or 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.
Execute any T54 seller operation by operationId with an optional query map. Prefer per-operation t54_* tools when available for clearer arguments. On HTTP 402, x402_broker_client pays then retries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Query string parameters as a JSON object. Keys must match OpenAPI query names for this operation (see resource openapi://agentic-swarm-t54-skus). | |
| operation_id | Yes | Exact OpenAPI operationId. Call t54_list_operations first. Known: agentCommerceData, airdropIntelligence, constitutionAuditLite, getHealth, helloPing, researchBrief, structuredQuery |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a meaningful non-obvious behavior beyond annotations: on HTTP 402, x402_broker_client pays then retries. This is valuable cost-relevant behavior. It does not explain what happens if the payment or retry fails, but the annotations (idempotent, non-destructive, open) already cover much of the safety profile.
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 compact clauses each carry distinct information: what the tool does, when to prefer alternatives, and what happens on payment-sourced HTTP 402. No filler, no repetition of the schema fields, and the most useful guidance 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?
For a generic, two-parameter dispatch tool with 100% schema description coverage, the description plus parameter docs provide enough to call it correctly: how to identify execution target, how to supply query parameters, which sibling to prefer, and how the payment retry behavior works. Since the tool is explicitly generic, enumerating every operation behavior would be both impossible and unnecessary.
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 baseline is 3. The tool description itself does not add much parameter meaning beyond calling the query an 'optional query map'; operation_id semantics are already covered in the schema with exact matching instructions, workflow guidance, and known values. The description neither corrects nor significantly enriches the structured parameter docs.
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?
States a specific verb and resource: execute any T54 seller operation by operationId with an optional query map. It also explicitly frames itself as a generic fallback, which distinguishes it from the per-operation t54_* siblings rather than merely restating the tool title.
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?
Gives direct selection guidance: prefer per-operation t54_* tools when available, implying this tool is the fallback for cases where no dedicated tool exists. The operation_id schema description also instructs to call t54_list_operations first, which is a concrete precondition.
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. Dates show when Glama detected each change.
contract_monitor_subscribe1 field changedInput schema / properties / thresholds / anyOfPrevious value: -[
- {
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]t54_x402_request1 field changedInput schema / properties / query / anyOfPrevious value: -[
- {
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]contract_audit1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "contract_auditOutput",
- "type": "object"
-}New value: +nullcontract_monitor_subscribe2 fields changedInput schema / properties / thresholds / anyOfPrevious value: -[
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "contract_monitor_subscribeOutput",
- "type": "object"
-}New value: +nullcontract_triage1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "contract_triageOutput",
- "type": "object"
-}New value: +nullt54_agent_commerce_data1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "_dyn_agentCommerceDataOutput",
- "type": "object"
-}New value: +nullt54_airdrop_intelligence1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "_dyn_airdropIntelligenceOutput",
- "type": "object"
-}New value: +nullt54_constitution_audit_lite1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "_dyn_constitutionAuditLiteOutput",
- "type": "object"
-}New value: +nullt54_get_health1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "t54_get_healthOutput",
- "type": "object"
-}New value: +nullt54_hello_ping1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "t54_hello_pingOutput",
- "type": "object"
-}New value: +nullt54_list_operations1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "t54_list_operationsOutput",
- "type": "object"
-}New value: +nullt54_research_brief1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "_dyn_researchBriefOutput",
- "type": "object"
-}New value: +nullt54_structured_query1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "_dyn_structuredQueryOutput",
- "type": "object"
-}New value: +nullt54_x402_request2 fields changedInput schema / properties / query / anyOfPrevious value: -[
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "t54_x402_requestOutput",
- "type": "object"
-}New value: +nullcontract_audit3 fields changedInput schema / properties / addresses / descriptionPrevious value: -"Comma-separated addresses (max 3)"New value: +"Comma-separated 0x addresses (max 3 proxy/implementation pairs)"Input schema / properties / chainIdRemoved value: -{
- "default": "eip155:8453",
- "description": "CAIP-2 chain id, default eip155:8453",
- "title": "Chainid",
- "type": "string"
-}Input schema / properties / chain_idAdded value: +{
+ "default": "eip155:8453",
+ "description": "CAIP-2 chain id (default Base mainnet eip155:8453)",
+ "title": "Chain Id",
+ "type": "string"
+}contract_monitor_subscribe7 fields changedInput schema / properties / addresses / descriptionPrevious value: -"Up to 10 contract addresses"New value: +"Up to 10 0x-prefixed EVM addresses to watch"Input schema / properties / durationDaysRemoved value: -{
- "default": 30,
- "title": "Durationdays",
- "type": "integer"
-}Input schema / properties / duration_daysAdded value: +{
+ "default": 30,
+ "description": "Subscription length in days (default 30; max per seller policy).",
+ "title": "Duration Days",
+ "type": "integer"
+}Input schema / properties / thresholds / descriptionPrevious value: -"Optional thresholds object"New value: +"Optional JSON object for alert sensitivity (e.g. liquidity drop %, admin key moves). Omit or {} for seller defaults."Input schema / properties / webhookUrlRemoved value: -{
- "description": "HTTPS webhook URL",
- "title": "Webhookurl",
- "type": "string"
-}Input schema / properties / webhook_urlAdded value: +{
+ "description": "HTTPS URL that receives POST alerts when risk thresholds breach",
+ "title": "Webhook Url",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "addresses",
- "webhookUrl"
-]New value: +[
+ "addresses",
+ "webhook_url"
+]contract_triage5 fields changedInput schema / properties / chainIdRemoved value: -{
- "default": "eip155:8453",
- "description": "CAIP-2 chain id, default eip155:8453",
- "title": "Chainid",
- "type": "string"
-}Input schema / properties / chain_idAdded value: +{
+ "default": "eip155:8453",
+ "description": "CAIP-2 chain id (default Base mainnet eip155:8453)",
+ "title": "Chain Id",
+ "type": "string"
+}Input schema / properties / contractAddressRemoved value: -{
- "description": "0x-prefixed EVM address",
- "title": "Contractaddress",
- "type": "string"
-}Input schema / properties / contract_addressAdded value: +{
+ "description": "0x-prefixed EVM contract address to screen",
+ "title": "Contract Address",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "contractAddress"
-]New value: +[
+ "contract_address"
+]t54_agent_commerce_data1 field changedInput schema / properties / depth / descriptionPrevious value: -"Query parameter `depth` for operation `agentCommerceData` (GET /x402/v1/agent-commerce-data). allowed values: standard, full; default: 'standard'."New value: +"Payload size — standard (smaller bundle) or full (more evidence rows)."t54_airdrop_intelligence4 fields changedInput schema / properties / context_note / descriptionPrevious value: -"Query parameter `context` for operation `airdropIntelligence` (GET /x402/v1/airdrop-intelligence). max length 4000."New value: +"Optional free-text context or links for the screening report (max 4000 chars)."Input schema / properties / contractAddressRemoved value: -{
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Optional EVM contract on Base for Tier-1 triage merge",
- "title": "Contractaddress"
-}Input schema / properties / contract_addressAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional EVM contract on Base for Tier-1 triage merge",
+ "title": "Contract Address"
+}Input schema / properties / topic / descriptionPrevious value: -"Query parameter `topic` for operation `airdropIntelligence` (GET /x402/v1/airdrop-intelligence). max length 256."New value: +"Airdrop or incentive topic to score (Farm Score, narrative screening)."t54_constitution_audit_lite1 field changedInput schema / properties / prompt_snippet / descriptionPrevious value: -"Query parameter `prompt_snippet` for operation `constitutionAuditLite` (GET /x402/v1/constitution-audit). max length 4000."New value: +"Text or agent instruction excerpt to screen for constitution / ethics heuristics (max 4000 chars)."t54_research_brief2 fields changedInput schema / properties / context_note / descriptionPrevious value: -"Query parameter `context` for operation `researchBrief` (GET /x402/v1/research-brief). max length 2000."New value: +"Optional extra context, URLs, or constraints for the brief (max 2000 chars)."Input schema / properties / topic / descriptionPrevious value: -"Query parameter `topic` for operation `researchBrief` (GET /x402/v1/research-brief). max length 256."New value: +"Subject line for the multi-section research brief (max 256 chars)."t54_structured_query1 field changedInput schema / properties / q / descriptionPrevious value: -"Query parameter `q` for operation `structuredQuery` (GET /x402/v1/query). max length 512; default: 'What is ethical agent commerce?'."New value: +"Natural-language question for a short constitution-safe answer (max 512 chars)."contract_auditcontract_monitor_subscribecontract_triaget54_agent_commerce_datat54_airdrop_intelligencet54_constitution_audit_litet54_get_healtht54_hello_pingt54_list_operationst54_research_brieft54_structured_queryt54_x402_requestClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
