Solana Mainnet verification, intelligence, machine receipts, and agent logistics through MCP.
Scored across 20 tools
Several tools occupy overlapping discovery/guidance territory: agent_match vs search_agents, pdao_services vs service_recommendation vs external_services, and the guide tools cover related how-to topics. Many entries are only described as 'PrivateDAO <name>' with no behavioral detail, so an agent has to guess boundaries between catalog, matching, and recommendation tools.
Names are readable and mostly snake_case, but the set mixes verb-first commands (create_paid_job, get_receipt, register_agent) with noun/adjective-phrase informational tools (exchange_overview, payment_guide, network_stats) and several noun+verb forms (agent_match, seller_replace_endpoint). Within seller_* and payment groups there is consistency, but no single naming convention across the server.
20 tools is on the heavy side for an exchange focused on discovery, paid jobs, and receipts. Several tools are static guide/explainer endpoints that could be consolidated into one help tool, and discovery could be reduced without much loss. Still, the count is not extreme and most tools map to real workflow steps.
The end-to-end exchange flow is covered: discovery/matching, paid job creation, payment, status polling, receipt retrieval, and verification, plus seller lifecycle management. Missing cancellation/refund or a list-my-jobs view are workable gaps rather than dead ends. The surface is reasonably complete for the stated purpose.
Free registry discovery and capability matching. Use create_paid_job for the paid agent.match service.
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Canonical network or accepted alias. | |
| capabilities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well established. The description adds only the 'free registry discovery and capability matching' framing, with no detail on rate limits, result behavior, or matching semantics.
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 short sentences carry the entire definition: one states what the tool does, the other names the paid alternative. There is no filler, and the key free-vs-paid distinction 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?
The description is workable for a simple read-only tool, especially with rich annotations. However, there is no output schema and the description does not explain what the tool returns or how it differs from search_agents, leaving meaningful gaps in a crowded sibling list.
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 network parameter is documented in the schema, but the capabilities parameter has no schema description. The phrase 'capability matching' gives capabilities a clear purpose, yet it does not explain matching rules or the expected format, leaving 50% schema coverage only partially compensated.
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 states a specific purpose: free registry discovery and capability matching. It clearly distinguishes itself from the paid create_paid_job service, but does not differentiate from the similar-sounding sibling search_agents.
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 says to use create_paid_job for the paid agent.match service, giving a clear when-not-to-use condition. However, it provides no guidance relative to other free siblings like search_agents, so the usage guidance is only partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO create_paid_job
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | Service-specific JSON input. | |
| service_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no informative annotations (all hints false) and no output schema, the description carries the burden of explaining side effects, payment behavior, idempotency, and return behavior, but it says nothing beyond the tool name. The name implies a create/write action but not what side effects, prerequisites, or consequences are involved.
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 brevity here is under-specification rather than efficient writing. It contains no informative content that an agent could act on.
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 paid, side-effectful creation tool with nested input and no output schema, the description omits essentially everything: how the payment is handled, what the input should contain per service, what response is returned, and how it connects to receipt/status siblings. This is not sufficient for safe 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 description adds no meaning for either parameter; service_id is only an enum and input is only described generically in the schema. The 50% schema coverage is not compensated by any description text.
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?
Tautological: description restates name/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?
There is no guidance on when to use this tool or how it differs from siblings such as submit_payment, job_status, or get_receipt. The agent is given no criteria to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here. Explain the PrivateDAO Agent Exchange as a service economy for AI agents: discover a capability, request it, receive a quote when paid, execute read-only evidence work, and verify the receipt.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds no side effects; it frames the tool purely as an explanation of the exchange. The 'read-only evidence work' phrasing reinforces the safe read-only nature, and there is no contradiction or hidden behavioral trap.
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?
A single sentence that front-loads the directive ('Start here'), states the subject, and enumerates the lifecycle in a compact, scannable list. Every clause contributes information, with no filler or redundancy.
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 overview tool, the description is largely complete: it tells an agent what the tool is for, what content it covers, and that it is the entry point. No output schema exists, but the expected explanatory text is implied by 'Explain'; a bit more about the return shape would push it higher.
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 no parameters, so the baseline is 4; the schema already documents all zero params at 100% coverage. The description appropriately focuses on content and purpose rather than parameter semantics, since there are no parameters to clarify.
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 the imperative 'Start here' and a clear verb-resource pair – 'Explain the PrivateDAO Agent Exchange' – then names the lifecycle stages (discover, request, quote, execute, verify). This distinguishes it from more targeted sibling guides like execution_guide or payment_guide, even though those siblings are not explicitly mentioned.
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?
'Start here' explicitly marks this as the entry point to the exchange tool family, giving an agent a clear condition for choosing it. It does not spell out when to prefer a sibling such as execution_guide or payment_guide, but the phrase provides strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain how to create a free or paid job, interpret 402 payment_intent, submit finalized payment proof, poll status, retrieve a receipt and verify it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context by stating it returns endpoints and state transitions rather than performing actions, which clarifies its output-oriented nature.
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 dense sentence front-loaded with 'Explain how to', followed by a precise workflow enumeration. Every phrase adds information and there is no filler or repetition of the input schema.
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 parameterless, read-only explainer tool, the description covers all major workflow stages the agent might need to route: create job, interpret 402, submit proof, poll, retrieve receipt, and verify. The schema description reinforces what the tool returns, so an agent can confidently select and 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?
The tool takes zero parameters and the schema description coverage is trivially 100%, so there is no parameter documentation burden. The baseline of 4 applies because no further parameter explanation is needed or possible.
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 ('Explain') and a concrete scope: the full job lifecycle from creation through payment, proof, polling, receipt, and verification. It distinguishes itself from action-oriented siblings like create_paid_job and submit_payment by clearly being a guide rather than an executor.
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 guide-like phrasing implies it should be used when the agent needs to explain or walk through the workflow, but there is no explicit when-to-use or when-not-to-use guidance. It does not name alternatives such as payment_guide or verify_basic, leaving some routing ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO external_services
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, providing a basic safety profile. However, the description adds zero behavioral context beyond that – no mention of what data is returned, any side effects, or how the tool behaves. Given the annotations, the description adds no value 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?
While the text is extremely short, this is under-specification rather than conciseness. The single sentence adds no information and fails to front-load any useful content. It is the antithesis of a helpful definition.
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 2 parameters, no output schema, and no description beyond the title, the definition is wholly inadequate. There is no mention of expected behavior, return values, or how to use the parameters. Even for a simple read-only tool, this is completely lacking.
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 0% – the parameters 'q' and 'limit' have no schema-level descriptions, and the description provides no meaning for them. An agent cannot infer what 'q' represents (query string?) or how 'limit' affects results. With 0% coverage, the description must compensate but does not.
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?
Tautological: description restates name/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?
There is no guidance on when to use this tool versus alternatives. The description offers no context, no prerequisites, and no mention of how it differs from tools like pdao_services or provider_integrations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO get_receipt
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the full safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. However, the description adds zero behavioral context beyond that — it discloses nothing about return format, failure modes, or what the agent should expect. It contributes nothing where the get_calls calibration example added scoping context and earned a 3.
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 words long, but this is under-specification, not deliberate conciseness. It contains zero informative content and fails to use its space to state scope, behavior, or parameter context.
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 carries the burden of explaining what the tool returns, and it says nothing at all. An agent cannot determine what a receipt represents, when the call succeeds, or how this differs from job_status — completely inadequate even for a one-parameter 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 0%, and the description must compensate per the rubric. 'PrivateDAO get_receipt' adds no meaning for receipt_id — it doesn't explain what a receipt_id is, where to obtain one, or how it relates to the siblings. Only the JSON Schema pattern '^rvr_[A-Za-z0-9]+$' hints at format, which 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?
Tautological: description restates name/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?
There is no guidance whatsoever about when to call this tool versus siblings like job_status or verify_basic, which could plausibly overlap as status/record-lookup tools. The description is empty rather than misleading, so it earns the 'no guidance' score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO job_status
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds no behavioral context at all. It does not describe what the status check returns, whether it reflects async progress, or any additional constraints beyond what annotations already say.
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 this is under-specification rather than effective conciseness. It has no informative content and does not front-load any scoping, parameters, behavior, or return details.
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?
Even though the tool has only one parameter and no nested objects, there is no output schema, so the description should explain what status information is returned. It provides none, leaving the agent unable to predict the call's result or meaning.
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 0%, so the description needed to compensate, but it says nothing about job_id or its meaning. The schema's pattern '^job_[A-Za-z0-9-]+$' is the only signal, and the description adds zero value beyond 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?
Tautological: description restates name/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?
There is no guidance about when to use this tool versus alternatives. No mention of job lifecycle context, prerequisites, or how job_status relates to create_paid_job, submit_payment, or get_receipt, leaving selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO logistics_request
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | ||
| network | No | Canonical network or accepted alias. | |
| deadline | No | ||
| maxPrice | No | ||
| capability | Yes | ||
| requirements | No | ||
| preferredProtocols | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, but the description adds zero behavioral context. It does not explain side effects, mutability, network interaction, or any operational 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?
The description is extremely short, but this is under-specification rather than concise communication. It contains no substantive content that 'earns its place' because it repeats the title verbatim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, nested objects, no output schema, and minimal schema descriptions; yet the description gives nothing about expected behavior, return values, or invocation context. It is wholly inadequate for an agent to call this 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?
Schema description coverage is only 14%, and the description offers no parameter explanations. With 7 parameters including an undocumented required 'capability' field, the tool does nothing to help the agent understand meaning, formatting, or relationships between 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?
Tautological: description restates name/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?
There is no guidance on when to use this tool, what problem it solves, or how it relates to sibling tools such as agent_match or create_paid_job. An agent receives no usable selection information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO network_stats
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond what annotations provide, such as response shape, scoping, or side-effect details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but is an under-specified tautology rather than a concise, informative statement. No sentence earns its place because the only words repeat the tool name.
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?
There is no output schema, and the description provides no return-value or result semantics. Although the empty parameter schema and safety annotations make invocation safe, an agent cannot know what data will be returned or how to interpret 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?
The schema has zero parameters and additionalProperties=false, so there is no parameter semantic burden. With no parameters, the description does not need to clarify parameter 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?
Tautological: description restates name/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?
The description gives no guidance on when to use this tool or when to prefer a sibling. It is not actively misleading, but it leaves all usage decisions to inference from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain the quote-first Solana Mainnet USDC payment flow. Never infer an amount, never pay before a payment_intent, and never request a private key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond those annotations: it is quote-first, must not infer amounts, must not pay before a payment_intent, and must never request a private key. This gives the agent actionable rules beyond the structured hints.
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 exceptionally concise: two short sentences with no wasted words. It front-loads the core purpose and immediately follows with the most important safety constraints. Every clause 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 read-only explanatory tool with no parameters, the description supplies the essential context: the flow is quote-first, on Solana Mainnet, uses USDC, and carries strict safety rules. It does not enumerate the full lifecycle or explain how payment_intent is obtained, but given the tool's educational role and rich annotations, the definition is largely 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?
The tool has zero parameters and the schema description fully covers what the tool returns ('Return the exact quote-first paid-service lifecycle and safety rules'). With no parameters, the description does not need to explain parameter semantics, so the baseline of 4 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 clearly states a specific verb and resource: 'Explain the quote-first Solana Mainnet USDC payment flow.' It also includes concrete guardrails ('Never infer an amount, never pay before a payment_intent, and never request a private key') that distinguish this informational tool from execution-oriented siblings like submit_payment or create_paid_job.
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 the tool is for explaining the payment flow, and the safety rules strongly suggest when not to perform actions, but it does not explicitly state when to use this guide versus alternatives. It lacks direct exclusion statements such as 'use submit_payment to actually pay' or 'use create_paid_job to request a quote.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the complete current catalog with service IDs, customer value, category, pricing, inputs, outputs, target networks and payment behavior.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds modest behavioral context by stating the result is a 'complete current catalog,' implying no filtering or stale snapshot, but it does not discuss pagination, response size, or refreshes, so some behavioral ambiguity remains.
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 states the action and object immediately, then lists the relevant output dimensions. Every listed field adds useful expectation-setting; there is no filler, repetition, or unnecessary context.
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, no-parameter, read-only catalog tool, the description is mostly complete: it enumerates the key return fields and indicates completeness and currency. However, there is no output schema to clarify return shape, and the description omits some details present in the schema description, such as access and runtime status, and gives no indication of pagination or result limits.
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 and the schema description covers the empty input object fully (100% coverage), so the description has no parameter burden to carry. The baseline for a zero-parameter tool is 4, and no additional parameter semantics are needed.
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 ('Return') and a clear resource ('the complete current catalog'), then itemizes the returned fields: service IDs, customer value, category, pricing, inputs, outputs, target networks, and payment behavior. This makes the tool's purpose unmistakable and clearly distinct from sibling tools like service_recommendation or verify_basic.
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 says what the tool does but gives no guidance on when to use it versus alternatives. It does not mention exclusions, such as 'use service_recommendation when you need a ranked recommendation' or 'use search/verify tools when looking up a single service.' The agent must infer the appropriate context from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain what IBM watsonx, Intel OpenVINO, MongoDB, GitHub, ChatGPT, Claude, Grok, OpenClaw and the PrivateDAO Kernel add to the ecosystem, with relationship disclosures and safe provider status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about output content ('relationship disclosures and safe provider status') but does not disclose operational details such as whether live integration checks are performed or whether results are cached. This is acceptable given the existing annotations, hence a middle 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?
A single, front-loaded sentence that lists the full scope of providers and the two key outputs ('relationship disclosures' and 'safe provider status'). No filler or repetition; every part adds 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 read-only informational tool with no parameters, the description covers the main content and is augmented by strong annotations. However, because there is no output schema, the description does not indicate the response format, and the lack of usage guidance leaves a noticeable gap for an agent deciding when to invoke this 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?
The tool has zero parameters, so there is nothing for the description to elaborate. The schema description ('without exposing credentials') adds a useful constraint, and the empty schema plus 100% coverage means no parameter documentation gap exists. Baseline 4 for zero-parameter tools 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 uses a specific verb ('Explain') and names a concrete set of providers (IBM watsonx, Intel OpenVINO, MongoDB, GitHub, ChatGPT, Claude, Grok, OpenClaw, PrivateDAO Kernel), making the tool's focus unambiguous. It does not explicitly contrast itself with sibling tools, so it misses the top score for active differentiation.
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 states what the tool does but gives no guidance on when a caller should choose it over siblings like pdao_services, service_recommendation, or exchange_overview. There are no context triggers, exclusions, or alternative routing hints, leaving the agent to infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO register_agent
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| tags | No | ||
| mcpUrl | No | Public HTTPS MCP endpoint | |
| payout | No | ||
| agentId | No | Stable seller identity for updates and endpoint replacement. | |
| mcp_url | No | Compatibility alias for mcpUrl. | |
| agent_id | No | Snake-case compatibility alias for agentId. | |
| endpoint | No | Compatibility alias for mcpUrl. | |
| networks | No | Explicitly declared supported networks; aliases are normalized. | |
| protocol | No | ||
| sellerId | No | Compatibility alias for agentId. | |
| seller_id | No | Snake-case compatibility alias for agentId. | |
| ownerToken | No | Seller ownership token; returned only once on first registration. | |
| owner_token | No | Snake-case compatibility alias for ownerToken. | |
| allowedTools | No | ||
| forceRefresh | No | Force a fresh MCP handshake instead of returning an existing healthy registration. | |
| allowed_tools | No | Snake-case compatibility alias for allowedTools. | |
| force_refresh | No | Snake-case compatibility alias for forceRefresh. | |
| acceptedAssets | No | ||
| accepted_assets | No | Snake-case compatibility alias for acceptedAssets. | |
| commercialServices | No | Explicit per-tool commercial metadata; prices are never inferred. | |
| persistUnavailable | No | Persist Unavailable after a failed health check; never marks it connected | |
| commercial_services | No | Snake-case compatibility alias for commercialServices. | |
| persist_unavailable | No | Snake-case compatibility alias for persistUnavailable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations convey idempotentHint=true, readOnlyHint=false, and openWorldHint=true, but the description adds no behavioral context beyond these structured hints. It does not disclose side effects, the one-time ownerToken, or the MCP handshake behavior that the schema's parameter descriptions hint at.
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 empty of information; this is under-specification rather than concise communication. There is no front-loaded actionable content to help an agent decide or prepare a call.
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?
This is a 24-parameter tool with nested objects, alias variants, and no output schema, yet the description is a single non-informative phrase. Crucial context—what a successful registration returns, how aliases are treated, and the effect of openWorldHint/idempotency—is missing, so the definition is not complete enough for correct 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?
With 75% schema description coverage, the schema already documents most parameters and their aliases, including significant behaviors like ownerToken returned only once and forceRefresh triggering a fresh handshake. The description adds no parameter-level meaning, but the schema largely carries the burden; a 3 reflects the remaining 25% gap left uncompensated.
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?
Tautological: description restates name/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?
No guidance is provided about when to call register_agent versus any of the 20 sibling tools. There is no mention of prerequisites (e.g., an MCP endpoint, ownership token) or when an existing registration would be reused via idempotency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO search_agents
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text registry search. | |
| limit | No | ||
| network | No | Canonical network or accepted alias. | |
| capability | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. However, the description itself adds no behavioral context—no return format, search semantics, rate limits, or edge cases—so it contributes nothing beyond 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?
While extremely short, this is under-specification rather than concise writing. The phrase adds no information beyond the name, and there is no structure (front-loaded purpose, examples, or scoping).
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?
There is no output schema, and the description gives no indication of return values, result ordering, or how the search behaves. Despite favorable annotations, an agent cannot tell what a successful call returns or how to interpret results, so the description is incomplete for a 4-parameter 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 only 50% (q and network have descriptions; limit and capability do not). The description provides no parameter semantics at all, leaving two parameters completely undocumented and the other two without additional 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?
Tautological: description restates name/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?
No guidance is provided about when to use this tool versus alternatives. The description contains no context, no examples, no conditions, and no exclusions, so an agent has no basis for selecting it over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO seller_replace_endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| mcp_url | Yes | ||
| agent_id | Yes | ||
| owner_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, but the description does not explain what these mean in practice or disclose any additional traits such as side effects, permissions, or side effects. No contradiction exists, but the description contributes zero value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It consists of a single title-like phrase with no structure, no front-loaded information, and no explanatory content. A proper concise description would still convey purpose and usage.
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 tool with three required parameters, no output schema, and no behavioral annotation detail, this description is wholly inadequate. An agent cannot infer what 'replace' means, what the parameters represent, what the side effects are, or what a successful call returns. Every essential piece of context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for three undocumented parameters (agent_id, owner_token, mcp_url). It does not mention any of them, their purpose, relationships, or expected formats. This is a complete failure to add semantic 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?
Tautological: description restates name/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?
There is no guidance on when to use this tool versus any of the 19 siblings. No conditions, exclusions, or alternative routing are provided. The description is entirely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO seller_retire
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| agent_id | Yes | ||
| owner_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits. Annotations indicate the operation is destructive and idempotent, but the description itself contributes zero context about what is removed, what ownership implications exist, or what the owner_token protects. It adds no value beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. A one-phrase label that repeats the title contains no usable information and is not an appropriately sized tool definition.
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 destructive tool with required authentication material, no output schema, and zero parameter or behavior documentation, the description is wholly inadequate. Nothing in it helps an agent safely and correctly invoke seller_retire.
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 0%, and the description names none of the parameters. agent_id, owner_token, and reason are completely unexplained, leaving an agent to guess their semantics and the token's authentication role.
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?
Tautological: description restates name/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?
There is no guidance about when to use this tool, what preconditions exist, or which alternative should be chosen instead. The sibling list includes closely related seller-management tools, but the description gives no basis for routing an agent to this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO seller_update_services
| Name | Required | Description | Default |
|---|---|---|---|
| payout | No | ||
| agent_id | Yes | ||
| services | Yes | ||
| owner_token | Yes | ||
| accepted_assets | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is non-readonly, open-world, idempotent, and non-destructive, but the description adds no behavioral context beyond what the annotations already state. It does not mention side effects, auth requirements, or any operational nuances, despite the presence of an 'owner_token' parameter implying access control.
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 repeated name with no structure. This is severe under-specification, not conciseness – every sentence should earn its place, but here there are no meaningful sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, nested objects, and no output schema, the description is completely inadequate. It provides none of the operational context an agent needs to call this 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 description provides zero information about any of the five parameters. With schema coverage at 0%, the description fails to compensate, leaving agents without any meaning for agent_id, owner_token, services, payout, or accepted_assets beyond their names.
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?
Tautological: description restates name/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?
No guidance is provided about when to use this tool versus alternatives. The description contains no context about selection criteria, prerequisites, or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map a natural-language task to the best available PrivateDAO services. Use this before create_paid_job when the user has not named a service ID.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Natural-language task the agent wants to accomplish. | |
| network | No | Optional target network constraint. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds contextual workflow guidance but no further behavioral traits such as failure modes, dynamic availability, or output format; 'best available' only hints at availability-awareness.
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 focused sentences with no filler. The first sentence states the core purpose, and the second gives actionable routing guidance. Every word contributes 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?
The tool is simple with 2 parameters, 1 required, and the description plus schema fully cover how to invoke it. The return concept—mapped/recommended services—is inferable from the stated purpose and the downstream reference to create_paid_job.
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 `task` and `network` are already well documented. The description reinforces that `task` is a natural-language request but adds no additional parameter-level semantics.
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 uses the specific verb 'Map' with a clear resource: natural-language task to best available PrivateDAO services. It explicitly distinguishes itself from create_paid_job by stating when it should be used, making the tool's role clear among siblings like pdao_services and agent_match.
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 when to use this tool: before create_paid_job when the user has not named a service ID. This provides both a positive trigger and an implied exclusion, and it names the relevant alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO submit_payment
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| signature | Yes | Finalized Solana transaction signature. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the operation as destructive, non-read-only, and non-idempotent, so the safety profile is partially available. However, the actual description discloses no behavioral context beyond that, such as whether funds move irreversibly, what state changes occur, or what happens to the referenced job.
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 this is under-specification rather than conciseness. It contains no information beyond the tool's title, so it does not earn its place as a meaningful definition.
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 financially significant, destructive operation with no output schema and no usage context, this description is severely incomplete. An agent cannot determine prerequisites, expected effects, sequencing relative to create_paid_job, or how to verify success afterward.
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 contributes zero parameter meaning. Schema coverage is only 50% because job_id has only a regex pattern and no semantic explanation, and the description does not compensate for that gap or clarify how job_id relates to the finalized Solana signature.
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?
Tautological: description restates name/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?
There is no guidance on when to call this tool, what prerequisite conditions must be met, or which alternatives should be used instead. Sibling tool names suggest a payment lifecycle, but the description gives the agent no basis for selecting submit_payment over create_paid_job or job_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PrivateDAO verify_basic
| Name | Required | Description | Default |
|---|---|---|---|
| mint | No | Solana mint address to inspect. | |
| asset | No | Alias for mint. | |
| record | No | Structured record to hash and verify. | |
| network | No | Optional target network identifier. | |
| expected_digest | No | Optional expected canonical digest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is already covered. The description adds no behavioral context beyond the annotations, but it does not contradict them either. With annotations carrying the burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It contains no information beyond the tool name, so it fails to earn its place as a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, an anyOf constraint, nested objects, and no output schema. The description provides zero context for how to invoke it correctly, what the verification does, or what the result means. This is completely inadequate for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no additional meaning about how parameters relate or how to choose between mint, asset, and record. Baseline 3 is correct when the schema does the heavy lifting.
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?
Tautological: description restates name/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?
There is no guidance on when to use this tool versus alternatives. The sibling tools include related operations like agent_match, get_receipt, and network_stats, but the description gives no context for selecting verify_basic. The schema's anyOf structure implies three usage modes, but the description does not explain them.
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.
register_agent9 fields changedInput schema / properties / accepted_assetsAdded value: +{
+ "description": "Snake-case compatibility alias for acceptedAssets.",
+ "items": {
+ "maxLength": 20,
+ "type": "string"
+ },
+ "maxItems": 20,
+ "type": "array"
+}Input schema / properties / agent_idAdded value: +{
+ "description": "Snake-case compatibility alias for agentId.",
+ "pattern": "^agent_[A-Za-z0-9_-]{8,100}$",
+ "type": "string"
+}Input schema / properties / allowed_toolsAdded value: +{
+ "description": "Snake-case compatibility alias for allowedTools.",
+ "items": {
+ "maxLength": 120,
+ "type": "string"
+ },
+ "maxItems": 64,
+ "type": "array"
+}Input schema / properties / commercial_servicesAdded value: +{
+ "description": "Snake-case compatibility alias for commercialServices.",
+ "items": {
+ "type": "object"
+ },
+ "maxItems": 64,
+ "type": "array"
+}Input schema / properties / force_refreshAdded value: +{
+ "description": "Snake-case compatibility alias for forceRefresh.",
+ "type": "boolean"
+}Input schema / properties / owner_tokenAdded value: +{
+ "description": "Snake-case compatibility alias for ownerToken.",
+ "maxLength": 200,
+ "minLength": 16,
+ "type": "string"
+}Input schema / properties / persist_unavailableAdded value: +{
+ "description": "Snake-case compatibility alias for persistUnavailable.",
+ "type": "boolean"
+}Input schema / properties / sellerIdAdded value: +{
+ "description": "Compatibility alias for agentId.",
+ "pattern": "^agent_[A-Za-z0-9_-]{8,100}$",
+ "type": "string"
+}Input schema / properties / seller_idAdded value: +{
+ "description": "Snake-case compatibility alias for agentId.",
+ "pattern": "^agent_[A-Za-z0-9_-]{8,100}$",
+ "type": "string"
+}external_servicesregister_agent5 fields changedInput schema / properties / acceptedAssetsAdded value: +{
+ "items": {
+ "maxLength": 20,
+ "type": "string"
+ },
+ "maxItems": 20,
+ "type": "array"
+}Input schema / properties / agentIdAdded value: +{
+ "description": "Stable seller identity for updates and endpoint replacement.",
+ "pattern": "^agent_[A-Za-z0-9_-]{8,100}$",
+ "type": "string"
+}Input schema / properties / commercialServicesAdded value: +{
+ "description": "Explicit per-tool commercial metadata; prices are never inferred.",
+ "items": {
+ "type": "object"
+ },
+ "maxItems": 64,
+ "type": "array"
+}Input schema / properties / ownerTokenAdded value: +{
+ "description": "Seller ownership token; returned only once on first registration.",
+ "maxLength": 200,
+ "minLength": 16,
+ "type": "string"
+}Input schema / properties / payoutAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "asset": {
+ "type": "string"
+ },
+ "network": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}seller_replace_endpointseller_retireseller_update_servicescreate_paid_job1 field changedInput schema / properties / service_id / enumPrevious value: -[
- "verify.deep",
- "token.intelligence",
- "risk.score",
- "wallet.intelligence",
- "contract.inspect",
- "launch.check",
- "market.snapshot",
- "research.asset",
- "research.wallet",
- "contract.explain",
- "transaction.explain",
- "anomaly.detect",
- "agent.research.report",
- "portfolio.intelligence",
- "swap.quote",
- "transaction.simulate",
- "decision.context",
- "forensics.trace",
- "agent.match",
- "sponsored.discovery",
- "intelligence.synthesize"
-]New value: +[
+ "verify.deep",
+ "token.intelligence",
+ "risk.score",
+ "wallet.intelligence",
+ "contract.inspect",
+ "launch.check",
+ "market.snapshot",
+ "research.asset",
+ "research.wallet",
+ "contract.explain",
+ "transaction.explain",
+ "anomaly.detect",
+ "agent.research.report",
+ "portfolio.intelligence",
+ "swap.quote",
+ "transaction.simulate",
+ "decision.context",
+ "github.repository",
+ "forensics.trace",
+ "agent.match",
+ "sponsored.discovery",
+ "intelligence.synthesize"
+]exchange_overviewexecution_guidepayment_guidepdao_services1 field changedInput schema / descriptionPrevious value: -"List available PrivateDAO services."New value: +"List every current PrivateDAO service with category, customer value, access, price, inputs, output, networks, runtime status and payment behavior."provider_integrationsservice_recommendationagent_match2 fields changedInput schema / propertiesAdded value: +{
+ "capabilities": {
+ "items": {
+ "maxLength": 120,
+ "type": "string"
+ },
+ "maxItems": 32,
+ "type": "array"
+ },
+ "network": {
+ "description": "Canonical network or accepted alias.",
+ "type": "string"
+ }
+}Input schema / requiredAdded value: +[
+ "capabilities"
+]create_paid_job2 fields changedInput schema / propertiesAdded value: +{
+ "input": {
+ "description": "Service-specific JSON input.",
+ "type": "object"
+ },
+ "service_id": {
+ "enum": [
+ "verify.deep",
+ "token.intelligence",
+ "risk.score",
+ "wallet.intelligence",
+ "contract.inspect",
+ "launch.check",
+ "market.snapshot",
+ "research.asset",
+ "research.wallet",
+ "contract.explain",
+ "transaction.explain",
+ "anomaly.detect",
+ "agent.research.report",
+ "portfolio.intelligence",
+ "swap.quote",
+ "transaction.simulate",
+ "decision.context",
+ "forensics.trace",
+ "agent.match",
+ "sponsored.discovery",
+ "intelligence.synthesize"
+ ],
+ "type": "string"
+ }
+}Input schema / requiredAdded value: +[
+ "service_id"
+]get_receipt2 fields changedInput schema / propertiesAdded value: +{
+ "receipt_id": {
+ "pattern": "^rvr_[A-Za-z0-9]+$",
+ "type": "string"
+ }
+}Input schema / requiredAdded value: +[
+ "receipt_id"
+]job_status2 fields changedInput schema / propertiesAdded value: +{
+ "job_id": {
+ "pattern": "^job_[A-Za-z0-9-]+$",
+ "type": "string"
+ }
+}Input schema / requiredAdded value: +[
+ "job_id"
+]logistics_request2 fields changedInput schema / propertiesAdded value: +{
+ "asset": {
+ "maxLength": 20,
+ "type": "string"
+ },
+ "capability": {
+ "maxLength": 120,
+ "type": "string"
+ },
+ "deadline": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "maxPrice": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "network": {
+ "description": "Canonical network or accepted alias.",
+ "type": "string"
+ },
+ "preferredProtocols": {
+ "items": {
+ "maxLength": 40,
+ "type": "string"
+ },
+ "maxItems": 8,
+ "type": "array"
+ },
+ "requirements": {
+ "type": "object"
+ }
+}Input schema / requiredAdded value: +[
+ "capability"
+]network_stats1 field changedInput schema / propertiesAdded value: +{}pdao_services2 fields changedInput schema / descriptionAdded value: +"List available PrivateDAO services."Input schema / propertiesAdded value: +{}register_agent2 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "mcpUrl"
+ ]
+ },
+ {
+ "required": [
+ "mcp_url"
+ ]
+ },
+ {
+ "required": [
+ "endpoint"
+ ]
+ }
+]Input schema / propertiesAdded value: +{
+ "allowedTools": {
+ "items": {
+ "maxLength": 120,
+ "type": "string"
+ },
+ "maxItems": 64,
+ "type": "array"
+ },
+ "endpoint": {
+ "description": "Compatibility alias for mcpUrl.",
+ "format": "uri",
+ "type": "string"
+ },
+ "forceRefresh": {
+ "description": "Force a fresh MCP handshake instead of returning an existing healthy registration.",
+ "type": "boolean"
+ },
+ "mcpUrl": {
+ "description": "Public HTTPS MCP endpoint",
+ "format": "uri",
+ "type": "string"
+ },
+ "mcp_url": {
+ "description": "Compatibility alias for mcpUrl.",
+ "format": "uri",
+ "type": "string"
+ },
+ "name": {
+ "maxLength": 200,
+ "type": "string"
+ },
+ "networks": {
+ "description": "Explicitly declared supported networks; aliases are normalized.",
+ "items": {
+ "maxLength": 80,
+ "type": "string"
+ },
+ "maxItems": 32,
+ "type": "array"
+ },
+ "persistUnavailable": {
+ "description": "Persist Unavailable after a failed health check; never marks it connected",
+ "type": "boolean"
+ },
+ "protocol": {
+ "enum": [
+ "MCP"
+ ],
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "maxLength": 64,
+ "type": "string"
+ },
+ "maxItems": 16,
+ "type": "array"
+ }
+}search_agents1 field changedInput schema / propertiesAdded value: +{
+ "capability": {
+ "maxLength": 120,
+ "type": "string"
+ },
+ "limit": {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "network": {
+ "description": "Canonical network or accepted alias.",
+ "type": "string"
+ },
+ "q": {
+ "description": "Free-text registry search.",
+ "maxLength": 200,
+ "type": "string"
+ }
+}submit_payment2 fields changedInput schema / propertiesAdded value: +{
+ "job_id": {
+ "pattern": "^job_[A-Za-z0-9-]+$",
+ "type": "string"
+ },
+ "signature": {
+ "description": "Finalized Solana transaction signature.",
+ "type": "string"
+ }
+}Input schema / requiredAdded value: +[
+ "job_id",
+ "signature"
+]verify_basic2 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "mint"
+ ]
+ },
+ {
+ "required": [
+ "asset"
+ ]
+ },
+ {
+ "required": [
+ "record"
+ ]
+ }
+]Input schema / propertiesAdded value: +{
+ "asset": {
+ "description": "Alias for mint.",
+ "type": "string"
+ },
+ "expected_digest": {
+ "description": "Optional expected canonical digest.",
+ "type": "string"
+ },
+ "mint": {
+ "description": "Solana mint address to inspect.",
+ "type": "string"
+ },
+ "network": {
+ "description": "Optional target network identifier.",
+ "type": "string"
+ },
+ "record": {
+ "description": "Structured record to hash and verify.",
+ "type": "object"
+ }
+}agent_match2 fields changedInput schema / propertiesRemoved value: -{
- "capabilities": {
- "items": {
- "maxLength": 120,
- "type": "string"
- },
- "maxItems": 32,
- "type": "array"
- },
- "network": {
- "description": "Canonical network or accepted alias.",
- "type": "string"
- }
-}Input schema / requiredRemoved value: -[
- "capabilities"
-]create_paid_job2 fields changedInput schema / propertiesRemoved value: -{
- "input": {
- "description": "Service-specific JSON input.",
- "type": "object"
- },
- "service_id": {
- "enum": [
- "verify.deep",
- "token.intelligence",
- "risk.score",
- "wallet.intelligence",
- "contract.inspect",
- "launch.check",
- "market.snapshot",
- "research.asset",
- "research.wallet",
- "contract.explain",
- "transaction.explain",
- "anomaly.detect",
- "agent.research.report",
- "portfolio.intelligence",
- "swap.quote",
- "transaction.simulate",
- "decision.context",
- "forensics.trace",
- "agent.match",
- "sponsored.discovery",
- "intelligence.synthesize"
- ],
- "type": "string"
- }
-}Input schema / requiredRemoved value: -[
- "service_id"
-]get_receipt2 fields changedInput schema / propertiesRemoved value: -{
- "receipt_id": {
- "pattern": "^rvr_[A-Za-z0-9]+$",
- "type": "string"
- }
-}Input schema / requiredRemoved value: -[
- "receipt_id"
-]job_status2 fields changedInput schema / propertiesRemoved value: -{
- "job_id": {
- "pattern": "^job_[A-Za-z0-9-]+$",
- "type": "string"
- }
-}Input schema / requiredRemoved value: -[
- "job_id"
-]logistics_request2 fields changedInput schema / propertiesRemoved value: -{
- "asset": {
- "maxLength": 20,
- "type": "string"
- },
- "capability": {
- "maxLength": 120,
- "type": "string"
- },
- "deadline": {
- "format": "date-time",
- "type": "string"
- },
- "maxPrice": {
- "minimum": 0,
- "type": "number"
- },
- "network": {
- "description": "Canonical network or accepted alias.",
- "type": "string"
- },
- "preferredProtocols": {
- "items": {
- "maxLength": 40,
- "type": "string"
- },
- "maxItems": 8,
- "type": "array"
- },
- "requirements": {
- "type": "object"
- }
-}Input schema / requiredRemoved value: -[
- "capability"
-]network_stats1 field changedInput schema / propertiesRemoved value: -{}pdao_services2 fields changedInput schema / descriptionRemoved value: -"List available PrivateDAO services."Input schema / propertiesRemoved value: -{}register_agent2 fields changedInput schema / anyOfRemoved value: -[
- {
- "required": [
- "mcpUrl"
- ]
- },
- {
- "required": [
- "mcp_url"
- ]
- },
- {
- "required": [
- "endpoint"
- ]
- }
-]Input schema / propertiesRemoved value: -{
- "allowedTools": {
- "items": {
- "maxLength": 120,
- "type": "string"
- },
- "maxItems": 64,
- "type": "array"
- },
- "endpoint": {
- "description": "Compatibility alias for mcpUrl.",
- "format": "uri",
- "type": "string"
- },
- "forceRefresh": {
- "description": "Force a fresh MCP handshake instead of returning an existing healthy registration.",
- "type": "boolean"
- },
- "mcpUrl": {
- "description": "Public HTTPS MCP endpoint",
- "format": "uri",
- "type": "string"
- },
- "mcp_url": {
- "description": "Compatibility alias for mcpUrl.",
- "format": "uri",
- "type": "string"
- },
- "name": {
- "maxLength": 200,
- "type": "string"
- },
- "networks": {
- "description": "Explicitly declared supported networks; aliases are normalized.",
- "items": {
- "maxLength": 80,
- "type": "string"
- },
- "maxItems": 32,
- "type": "array"
- },
- "persistUnavailable": {
- "description": "Persist Unavailable after a failed health check; never marks it connected",
- "type": "boolean"
- },
- "protocol": {
- "enum": [
- "MCP"
- ],
- "type": "string"
- },
- "tags": {
- "items": {
- "maxLength": 64,
- "type": "string"
- },
- "maxItems": 16,
- "type": "array"
- }
-}search_agents1 field changedInput schema / propertiesRemoved value: -{
- "capability": {
- "maxLength": 120,
- "type": "string"
- },
- "limit": {
- "maximum": 100,
- "minimum": 1,
- "type": "integer"
- },
- "network": {
- "description": "Canonical network or accepted alias.",
- "type": "string"
- },
- "q": {
- "description": "Free-text registry search.",
- "maxLength": 200,
- "type": "string"
- }
-}submit_payment2 fields changedInput schema / propertiesRemoved value: -{
- "job_id": {
- "pattern": "^job_[A-Za-z0-9-]+$",
- "type": "string"
- },
- "signature": {
- "description": "Finalized Solana transaction signature.",
- "type": "string"
- }
-}Input schema / requiredRemoved value: -[
- "job_id",
- "signature"
-]verify_basic2 fields changedInput schema / anyOfRemoved value: -[
- {
- "required": [
- "mint"
- ]
- },
- {
- "required": [
- "asset"
- ]
- },
- {
- "required": [
- "record"
- ]
- }
-]Input schema / propertiesRemoved value: -{
- "asset": {
- "description": "Alias for mint.",
- "type": "string"
- },
- "expected_digest": {
- "description": "Optional expected canonical digest.",
- "type": "string"
- },
- "mint": {
- "description": "Solana mint address to inspect.",
- "type": "string"
- },
- "network": {
- "description": "Optional target network identifier.",
- "type": "string"
- },
- "record": {
- "description": "Structured record to hash and verify.",
- "type": "object"
- }
-}agent_matchcreate_paid_jobget_receiptjob_statuslogistics_requestnetwork_statspdao_servicesregister_agentsearch_agentssubmit_paymentverify_basicNative Solana staking for AI agents. 26 MCP tools, one-shot signing, webhooks.
Solana on-chain intelligence — token scans, wallet profiling, bundle detection, 19 MCP tools.
Solana-native MCP gateway for SAP, DeFi tools, SNS identity, and x402 payments.
Multi-agent coordination protocol on Solana. Swarm formation, on-chain settlement, 14 MCP tools.
Add one secure layer between your agents and this server.
