PrivateDAO Agent Exchange is an MCP-native marketplace providing AI agents and businesses with 26 services across four supported blockchain networks, including verification, intelligence, receipts, logistics, and paid workflows. Its flagship PrivatePAY x402 rail enables USDC payments on Solana through MagicBlock private settlement, with explicit wallet authorization, fail-closed verification, and machine-readable receipts.
Scored across 17 tools
Descriptions work hard to draw boundaries, but three discovery-style tools (discover_agents, list_catalog, service_recommendation) and three payment-initiation paths (create_paid_job with payment_mode=privatepay, privatepay_checkout, privatepay_challenge) still overlap enough to cause misselection. The privatepay_* pipeline (challenge → verify → settle) is reasonably staged, but privatepay_job_payment vs submit_payment differ only by payment mode, which an agent can easily get wrong.
Everything is snake_case and the privatepay_ namespace prefix is a genuine plus, but verb conventions are mixed: verb_noun (cancel_job, create_paid_job, submit_payment), get_* (get_workflow_guide, get_provider_integrations), and bare noun-status (job_status, privatepay_status). The inconsistency between get_*-prefixed read tools and noun-first status tools is readable but not predictable.
17 tools is on the heavy side, but the domain (paid agent exchange plus a multi-step private payment protocol) genuinely requires the breadth; seven privatepay_* tools map to distinct pipeline stages. It is slightly over-provisioned on the discovery/read side rather than bloated overall.
The core lifecycle (discover → create → pay → status → cancel → verify receipt) is covered, but there is no job listing/history tool, no refund or dispute path, and no way to register an agent despite repeated references to 'registered agents'. Cancel is limited to unpaid jobs with no recovery route, which will dead-end some workflows.
Cancel an unpaid pending request before execution and return its updated status. It records cancellation only, never spends or refunds funds, and must not be used after payment or execution has started.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The unpaid pending request to cancel. | |
| reason | No | Optional operational reason recorded with the cancellation. |
| Name | Required | Description |
|---|---|---|
| job_id | No | Cancelled request identifier. |
| status | No | Updated cancellation state. |
| cancelled_at | No | Cancellation timestamp when recorded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful context beyond those annotations: it records cancellation only, never spends or refunds funds, and must not be used after payment or execution. That clarifies the mutation's limited blast radius. It does not explicitly mention idempotency, but annotations cover that.
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 compact sentences with the core action and precondition front-loaded. Every clause adds useful constraint or behavioral context with no wasted text.
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 full schema coverage, rich annotations, and an existing output schema, the description supplies all the essential behavioral and usage context an agent needs. The preconditions and non-refund semantics are the key missing pieces, and they are present.
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%, and both parameters are well documented in the schema, including the required job_id format and optional reason semantics. The description does not add parameter-specific meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Cancel') and resource ('unpaid pending request') with a clear scope: before execution. It distinguishes itself from payment and execution-related siblings by explicitly scoping to unpaid, pending requests.
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?
It gives an explicit precondition ('before execution') and a clear when-not rule ('must not be used after payment or execution has started'). It does not name an alternative tool for post-payment scenarios, but the usage boundary is otherwise unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a selected paid PrivateDAO capability request and return an immediate result or exact quote-first payment intent. Use discover_agents or list_catalog first; payment_mode=privatepay starts the PrivatePAY flow, while direct uses ordinary USDC. This call never spends funds.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | Service-specific JSON input matching the selected service schema. | |
| service_id | Yes | Paid service identifier selected from list_catalog or discover_agents. | |
| pdao_access | No | Optional signed PDAO holder challenge from /api/access/challenge. | |
| payment_mode | No | Select privatepay only when the PrivatePAY x402 status is enabled. | direct |
| Name | Required | Description |
|---|---|---|
| job_id | No | Stable request identifier. |
| result | No | Service result when the request completes immediately. |
| status | No | Request status, commonly awaiting_payment or completed. |
| receipt | No | Public receipt metadata when the request completes. |
| payment_intent | No | Exact quote and recipient details when payment is required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real value beyond annotations: the no-spend guarantee ('This call never spends funds') is a critical safety clarification for a tool that looks like a purchase, and the branching between immediate execution and a quote-first intent clarifies non-idempotent behavior. Annotations only say readOnly=false, destructive=false, idempotent=false; the description explains what actually happens to funds and what comes back.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, routing prerequisites, mode semantics, and the safety guarantee. The no-spend reassurance is placed where a cautious agent will see it before committing.
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 an output schema present, the description only needs to frame the return shape, which it does ('immediate result or exact quote-first payment intent'). The mutation semantics, prerequisites, and no-spend guarantee make it callable without opening other docs; only the optional pdao_access challenge path is left entirely to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description goes beyond it by explaining what payment_mode values actually cause (PrivatePAY flow vs ordinary USDC) and by framing the returned quote as an input to a separate payment tool. It does not explain pdao_access or the service-specific input object, but those are adequately covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a selected paid PrivateDAO capability request') and names the outcome shape (immediate result vs quote-first payment intent). It distinguishes itself from catalog/discovery siblings by naming discover_agents and list_catalog as prerequisites rather than substitutes.
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 an explicit ordering rule ('Use discover_agents or list_catalog first') and a decision rule for the mode parameter (privatepay starts the PrivatePAY flow, direct uses ordinary USDC), plus a follow-up pointer to 'the matching payment tool'. It lacks an explicit when-not / failure-case statement, but the routing guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Match a natural-language requirement or structured capabilities to first-party services and registered agents. Returns ranked matches without side effects or cost; use list_catalog for exact schemas and prices, and create_paid_job to execute selected paid work.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of ranked agent matches to return. | |
| query | No | Natural-language business requirement or capability request. | |
| network | No | Optional target network constraint used to filter compatible matches. | |
| capabilities | No | Structured capability terms to match against registered agents. |
| Name | Required | Description |
|---|---|---|
| query | No | Natural-language query echoed by the matcher. |
| agents | No | Registered agent matches. |
| matches | No | Ranked first-party service matches. |
| first_party | No | PrivateDAO first-party discovery entry. |
| capabilities | No | Capability terms used for matching. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description still adds value by stating 'without side effects or cost' and by describing the output as ranked matches, which the agent needs to know before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, followed immediately by the sibling-routing guidance. No wasted text.
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?
An output schema exists, so return values need no explanation. The description covers purpose, cost/side-effect profile, and alternatives, which is everything needed to invoke it 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 100%, so all four parameters are documented, and the baseline is 3. The description echoes the two input modes (natural-language vs. structured capabilities) but adds no syntax, formatting, or weighting detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: matches a natural-language requirement or structured capabilities to first-party services and registered agents. It distinguishes itself from siblings by naming list_catalog and create_paid_job as the tools for adjacent steps.
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?
Explicitly routes the agent: use list_catalog for exact schemas and prices, and create_paid_job to execute selected paid work. This makes the discovery-vs-inspect-vs-execute decision unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return provider roles and integration metadata for planning. This is free and read-only; use list_catalog for purchasable capabilities and discover_agents for matching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| disclosure | No | Boundary explaining what the integration records do and do not prove. |
| integrations | No | Provider and ecosystem integration records. |
| provider_status | No | Public readiness signals with secrets removed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile needs no repetition. The description does add one trait the annotations cannot express: it states that calls are free, which helps the agent decide whether to call this tool speculatively. No further details about return shape or rate limits are given, but the annotations carry most of the burden and the output schema exists.
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?
There are two sentences, both front-loaded: the first states the return value, and the second states cost plus the alternative routing. No sentence repeats itself, and no space goes to boilerplate.
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 tool with a full output schema and rich annotations, the description covers purpose, cost and sibling routing, which is enough to call the tool correctly. The only gap is that 'provider roles ... for planning' does not say what an agent would concretely use the data for, though the output schema covers the return shape.
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 no parameters, so the baseline is 4 for a description that says nothing about them. There is nothing for the description to clarify, and the schema's 100% coverage of the empty properties set also means there is nothing it should cover.
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 gives a specific verb ('Return') plus the resource ('provider roles and integration metadata') and names its two siblings, so the agent can distinguish it from list_catalog and discover_agents. It falls short of a 5 only because 'provider roles' and 'integration metadata' remain somewhat abstract compared with what a fully concrete definition would state.
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 assigns each sibling a job: list_catalog is for 'purchasable capabilities' and discover_agents is for 'matching'. That gives the agent both a positive signal for when to pick this tool and clear exclusions for when to pick another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the overview, execution, or payment workflow guide. Use this instead of separate guide tools when you need lifecycle context; it is free, read-only, and returns the selected next steps without executing or paying.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Choose the lifecycle guide needed before discovery, execution, or payment. |
| Name | Required | Description |
|---|---|---|
| free | No | Free-service path when the payment topic is selected. |
| name | No | Exchange or workflow name. |
| paid | No | Ordered paid-service steps when the payment topic is selected. |
| rules | No | Safety rules for the selected workflow. |
| states | No | Possible request states. |
| payment | No | Payment rules for the selected workflow. |
| endpoints | No | Machine endpoints for the selected workflow. |
| lifecycle | No | Ordered lifecycle stages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds genuinely new traits: the call is free, returns next steps, and has no side effects on execution or payment. This is real value beyond the structured hints, though it does not say anything about ordering or whether guides reference later steps.
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 compact sentences with the purpose front-loaded and the routing/constraint info second. "it is free, read-only" slightly duplicates the annotations, but the waste is minimal.
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 single-enum, read-only lookup tool with an output schema and full annotation coverage, the description covers purpose, cost, and safety adequately. The only residual gap is that it references non-existent "separate guide tools," which could confuse an agent scanning the 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?
Schema description coverage is 100% and the enum values are already documented with per-value guidance ("before discovery, execution, or payment"). The description only restates the three topic names, adding no format or selection nuance beyond the schema — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Return") and resource ("overview, execution, or payment workflow guide"), and enumerates the three topic variants so the agent knows the scope without opening the schema. The sibling differentiation is weakened because it says to use it "instead of separate guide tools," but no such tools exist in the sibling list, leaving the agent to guess what it replaces.
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?
"Use this instead of separate guide tools when you need lifecycle context" gives an explicit trigger and a named alternative, and the trailing clause clarifies a when-not (it does not execute or pay). The guidance is clear but slightly abstract — "lifecycle context" is not tied to concrete agent goals like 'before calling create_paid_job'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current state, exact payment intent, result, or receipt reference for a request. Poll this after create_paid_job, privatepay_job_payment, or submit_payment; it is free and read-only, never retries payment, and never executes work again.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job identifier returned by create_paid_job; polling never retries or charges payment. |
| Name | Required | Description |
|---|---|---|
| job_id | No | Stable request identifier. |
| result | No | Service result when complete. |
| status | No | Current request state. |
| receipt_id | No | Receipt identifier when available. |
| payment_intent | No | Exact quote when payment is pending. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description usefully reinforces this by stating it is free, never retries payment, and never re-executes work — meaningful safety context for a polling tool beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero waste; the core purpose and the safety reassurance are front-loaded, and the usage cue follows immediately.
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 an output schema present, the description needn't explain return values, and it covers purpose, usage timing, and the non-charging/non-retry guarantee. Nothing an agent needs to call it correctly 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?
Only one parameter with 100% schema description coverage, so the schema already documents job_id, its pattern, and its origin. The description adds no syntax or format detail beyond what the schema and its field description already provide, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Read) and resource (current state, payment intent, result, receipt reference for a request), and ties it to prior creation/payment tools. It doesn't clarify how it differs from the sibling privatepay_status, leaving some ambiguity about which status tool to call.
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?
Explicitly says when to use it: 'Poll this after create_paid_job, privatepay_job_payment, or submit_payment.' That is clear context for invocation. It stops short of an exclusion vs privatepay_status, so routing between the two status tools is left partly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List services, products, external capabilities, or network metadata with optional filters. This is free and read-only; use discover_agents for a task-specific match and create_paid_job only after selecting a service.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Optional business or capability text used to filter catalog entries. | |
| limit | No | Maximum number of entries returned in each selected catalog slice. | |
| filter | No | Select the catalog slice to return. | all |
| Name | Required | Description |
|---|---|---|
| filter | No | Catalog slice used for the response. |
| network | No | Supported network capability metadata. |
| external | No | Published external capability metadata. |
| products | No | Productized workflow metadata. |
| services | No | First-party and published service metadata. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description's 'read-only' restates that but adds the non-annotation fact that the call is free (no payment/challenge flow). The workflow ordering constraint around create_paid_job is also useful behavioral context. It stops short of describing pagination or slice-return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The capability enumeration and the cost/read-only constraint are front-loaded before the alternative-tool routing, which is the right ordering for an agent deciding whether to call it.
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?
An output schema exists, so return values needn't be explained, and the three optional parameters are fully specified in schema. Annotations cover safety and idempotency. Minor gap: nothing about default behavior when no filter/query is supplied, though the limit default (50) and slice semantics are documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so q, limit, and filter are already fully documented in the schema with defaults and bounds. The description's mention of 'optional filters' adds no syntax or semantics beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and enumerates the exact resource slices (services, products, external capabilities, network metadata) that map one-to-one onto the filter enum. It also names discover_agents as the contrasting tool, so an agent can distinguish browsing from task-matching without opening either schema.
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?
Explicitly describes the selection logic: this tool for free read-only listing, discover_agents for a task-specific match, and create_paid_job only after a service has been selected. That is a genuine when-to-use / when-to-use-something-else routing rule rather than implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a fresh PrivatePAY x402 v2 challenge for a resource and quoted USDC amount. Call this before privatepay_verify; it returns exact payment requirements and the PDAO private-settlement rule, but never signs, broadcasts, or charges a wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | No | Optional caller nonce used to bind a fresh challenge. | |
| resource | Yes | Stable HTTPS resource or service identifier being purchased. | |
| mime_type | No | Optional response media type for the purchased resource. | |
| provider_id | Yes | PrivatePAY provider or merchant identifier. | |
| amount_base_units | Yes | Quoted USDC amount in token base units, not a decimal display amount. |
| Name | Required | Description |
|---|---|---|
| privacy | No | Redacted privacy boundary for the challenge. |
| request_id | No | Fresh challenge or payment request identifier. |
| payment_required | No | Exact x402 v2 requirements to present to the payer. |
| payment_required_header | No | HTTP PAYMENT-REQUIRED value when returned by the checkout flow. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds genuine context beyond the annotations: it 'never signs, broadcasts, or charges a wallet,' which resolves the tension of readOnlyHint=false and confirms non-destructive behavior, and it discloses the return payload (payment requirements plus PDAO private-settlement rule). It does not explain challenge lifetime/expiry or how idempotentHint=true interacts with the 'fresh challenge' language and the optional nonce.
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 dense sentences, front-loaded with the action and followed by the ordering constraint and safety guarantee. No filler or restatement of 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?
Annotations plus an output schema carry most of the load, and the description covers preconditions and side-effect profile well. It leaves ambiguous how this challenge relates to privatepay_prepare/settle/checkout in the broader payment flow, which matters given the crowded privatepay_* family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all five parameters are already documented in the schema, including the base-units caveat. The description only restates resource and amount at a high level and adds no semantics for provider_id, mime_type, or nonce binding, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Create a fresh PrivatePAY x402 v2 challenge' with the inputs (resource, quoted USDC amount) named. It distinguishes itself from privatepay_verify by stating ordering, but not from other siblings such as privatepay_prepare, privatepay_checkout, or privatepay_settle.
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?
Explicit sequencing: 'Call this before privatepay_verify.' The pre-condition is also reinforced in the schema description ('after checking rail status'). No when-not guidance or alternative routing against the other privatepay_* tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a MagicBlock PrivatePAY checkout or request the payment-required challenge for an existing checkout. Use this to begin a private checkout instead of create_paid_job with direct USDC; it returns commercial terms only and never signs, broadcasts, or moves funds.
| Name | Required | Description | Default |
|---|---|---|---|
| payer | No | Solana payer wallet public key; never a private key. | |
| phase | No | Use create for a new checkout or challenge to request the payment-required response for an existing payment_id. | create |
| resource | No | HTTPS resource or service endpoint being purchased. | |
| payment_id | No | Existing 64-character checkout identifier when phase is challenge. | |
| description | No | Human-readable commercial description shown in the checkout response. | |
| amount_base_units | No | Quoted USDC amount in base units. | |
| expires_in_seconds | No | Challenge lifetime in seconds, between one minute and one day. | |
| external_reference | No | Merchant-owned idempotency or order reference. |
| Name | Required | Description |
|---|---|---|
| status | No | Checkout state or next action. |
| payment_id | No | Checkout identifier used to request the challenge or continue the checkout. |
| payment_required | No | Exact x402 v2 requirements when the challenge phase is requested. |
| payment_required_header | No | HTTP PAYMENT-REQUIRED value when returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations say readOnlyHint=false, so an agent might assume a mutation; the description corrects this by stating it 'never signs, broadcasts, or moves funds' and 'returns commercial terms only.' That is genuine value beyond the annotations, though it doesn't mention auth requirements or what happens to an existing payment_id on re-create.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and immediately followed by the differentiator and the safety constraint. No filler.
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?
Output schema exists, so return-value detail is unnecessary, and idempotency is covered by idempotentHint. What remains thin is prerequisite/error context (what happens if payment_id is invalid or if phase is omitted for an existing checkout).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is already documented with patterns and bounds. The description adds only a light gloss on the create/challenge phase distinction, which the phase enum already conveys. Baseline 3 is correct.
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: 'Create a MagicBlock PrivatePAY checkout or request the payment-required challenge for an existing checkout.' It also distinguishes the tool from the sibling create_paid_job with direct USDC, so an agent can route between them without opening schemas.
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 explicit routing guidance ('use this instead of create_paid_job with direct USDC') and the schema's phase enum spells out create vs challenge. It stops short of naming the closely related siblings privatepay_challenge / privatepay_prepare and their conditions, which would be needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a finalized PrivatePAY x402 payment to an existing paid job and execute it once. Use this instead of submit_payment for a job created with payment_mode=privatepay; it consumes supplied payment proof, may settle funds, and returns workflow evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job identifier returned by create_paid_job. | |
| payment_signature | Yes | The x402 PAYMENT-SIGNATURE value returned by the paying agent wallet. |
| Name | Required | Description |
|---|---|---|
| job_id | No | Paid workflow job identifier. |
| result | No | Service result when execution completes. |
| status | No | Job or payment state after applying the supplied x402 proof. |
| receipt | No | Public evidence receipt when execution completes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the risk profile is known. The description adds real value beyond that: it consumes supplied payment proof, may settle funds, executes only once, and returns workflow evidence. It stops short of saying what a retry does after a partial settlement or what failure leaves behind, which matters for a non-idempotent money-moving call.
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?
One dense sentence, front-loaded with the action and followed immediately by the sibling routing rule. Every clause contributes: the action, the alternative, the mode condition, the side effects, and the return shape.
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?
An output schema exists, so return values ('workflow evidence') need only be gestured at, and the description does that. For a destructive, non-idempotent payment-settlement call, the main remaining gap is post-failure or duplicate-submission behavior, which the description does not address despite saying 'execute it once.'
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%, including provenance ('returned by create_paid_job') and the x402 PAYMENT-SIGNATURE origin, so the schema carries the parameter burden. The description adds only the notion of 'supplied payment proof' being consumed, which is a restatement rather than new syntax or format detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Apply a finalized PrivatePAY x402 payment to an existing paid job and execute it once.' It names the sibling it replaces (submit_payment) and the discriminating job attribute (payment_mode=privatepay), so the agent can tell it apart from submit_payment without opening either schema.
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?
It states the selection condition explicitly ('for a job created with payment_mode=privatepay') and names the alternative it substitutes ('Use this instead of submit_payment'). There is essentially no inference needed to route between this and submit_payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for a local wallet to inspect and sign. Call this after privatepay_checkout and before wallet authorization; PrivateDAO never receives a private key and this tool never broadcasts.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | No | Optional destination or balance owner public key. | |
| payer | No | Wallet public key that will inspect and authorize the transaction. | |
| phase | No | Unsigned wallet operation to prepare after the challenge: deposit into the private rail, private transfer, or withdrawal. | transfer |
| split | No | Optional private transfer split count, from one to fifteen. | |
| gasless | No | Request the configured sponsored route when supported; the wallet still signs the returned transaction. | |
| request_id | Yes | PrivatePAY request identifier returned by the challenge or checkout. | |
| amount_base_units | Yes | Token amount in base units. |
| Name | Required | Description |
|---|---|---|
| phase | No | Prepared private-rail operation. |
| request_id | No | PrivatePAY request identifier bound to the unsigned operation. |
| transaction | No | Serialized unsigned transaction when the provider returns one. |
| required_signers | No | Wallet public keys that must sign locally. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context beyond those fields: the output is unsigned, PrivateDAO never receives a private key, and the tool never broadcasts. It does not cover rate limits or error behavior, so it falls short of a 5.
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 tightly written sentences with no repetition. The action and sequencing guidance are front-loaded before the safety notes.
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 full schema coverage, an output schema, and rich safety annotations, the description supplies the remaining workflow and custody context an agent needs: when to call it and what it will not do. Nothing material 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 100%, including the phase enum, split bounds, and gasless behavior. The description names the three supported operations but does not add syntax, format, or default-value meaning beyond what the schema already provides. The baseline 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?
States a specific verb and resource: prepare an unsigned deposit, private transfer, or withdrawal for local wallet inspection and signing. This clearly distinguishes it from sibling tools like privatepay_checkout and privatepay_settle.
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?
Explicitly places the tool in the flow: call after privatepay_checkout and before wallet authorization. Naming the adjacent sibling tools leaves little ambiguity about when this step is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Settle an already verified x402 v2 PrivatePAY payload through the configured facilitator and return redacted settlement evidence. Call this only after privatepay_verify with unchanged requirements; this is the payment-moving action and may create facilitator-side or on-chain settlement.
| Name | Required | Description | Default |
|---|---|---|---|
| x402Version | Yes | Must be x402 protocol version 2. | |
| paymentPayload | Yes | The same finalized payer payload that passed privatepay_verify. | |
| paymentRequirements | Yes | The unchanged requirements from the original PrivatePAY challenge. |
| Name | Required | Description |
|---|---|---|
| status | No | Settlement status. |
| settled | No | Whether the facilitator accepted settlement. |
| evidence | No | Redacted settlement evidence; provider secrets and sensitive payment payloads are excluded. |
| request_id | No | Redacted PrivatePAY request identifier when available. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the description's job is to add context, which it does by disclosing that it moves payment and may create facilitator-side or on-chain settlement, plus that output is redacted. It stops short of warning about duplicate settlement on retry (relevant since idempotentHint=false with real money) or permission/config prerequisites for the facilitator.
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, no filler, with the prerequisite and the destructive side effect front-loaded before any agent commits to the call. Every clause carries decision-relevant 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?
Output schema exists, so return-value detail is unnecessary, and annotations carry the safety profile. The description supplies the precondition and mutation scope, leaving only retry/idempotency guidance and failure-mode behavior as gaps for a money-moving operation.
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 schema's own property descriptions already say the payload must be 'the same finalized payer payload that passed privatepay_verify' and requirements must be 'unchanged.' The description's 'unchanged requirements' phrasing echoes that, adding little beyond the structured fields; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Settle), a specific resource (an already verified x402 v2 PrivatePAY payload), the execution channel (configured facilitator), and the return (redacted settlement evidence). This distinguishes it cleanly from privatepay_verify and other siblings without needing to open the schema.
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?
Explicitly gated: 'Call this only after privatepay_verify with unchanged requirements', naming the prerequisite sibling tool and the condition that selects it. It also flags this as the payment-moving action, which tells an agent when this tool is the right choice versus the read-only verification steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current PrivatePAY x402 readiness, MagicBlock private-rail configuration, facilitator state, PDAO entry requirement, and public-chain privacy boundary. Call this first; it is free and read-only, creates no challenge, and never moves funds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| enabled | No | Whether the private settlement rail is currently enabled for new payment operations. |
| network | No | Settlement network identifier. |
| privacy | No | Provider-visible and public-chain privacy boundaries. |
| pdao_required | No | Whether the private path requires the PDAO entry policy. |
| settlement_mode | No | Configured provider settlement mode. |
| activation_blockers | No | Explicit blockers when the rail is unavailable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds value beyond them by asserting the call is free (a cost trait annotations cannot express) and that it creates no challenge and never moves funds, which is the domain-specific risk an agent needs to know before sequencing payment tools.
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?
One sentence to enumerate the reported state, one short clause to establish the call-first ordering and safety profile. Front-loaded, no filler, every clause carries 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?
With no parameters and an output schema present, the description only needs to convey purpose, sequencing, and safety, all of which it covers. Nothing required to invoke this correctly 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?
Zero parameters, so there is nothing for the description to disambiguate and the schema is trivially complete. Baseline 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?
States a specific verb ("Read") and enumerates the exact resources returned: x402 readiness, MagicBlock rail config, facilitator state, PDAO entry requirement, and public-chain privacy boundary. This is clearly distinguishable from the sibling privatepay_challenge/prepare/settle/verify tools, which act rather than report.
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?
"Call this first" gives explicit ordering guidance relative to the other privatepay_* siblings, and the free/read-only framing tells the agent this is the safe entry point. It stops short of naming which sibling to move to next or stating exclusions, so it is clear context rather than a full decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an x402 v2 PrivatePAY payload through the configured facilitator against the exact original requirements. Call this after privatepay_challenge or privatepay_checkout and before privatepay_settle; it is read-only, fail-closed, and returns redacted evidence without spending funds.
| Name | Required | Description | Default |
|---|---|---|---|
| x402Version | Yes | Must be x402 protocol version 2. | |
| paymentPayload | Yes | The payer wallet's finalized x402 payment payload, including the accepted scheme and transaction proof. | |
| paymentRequirements | Yes | The exact requirements returned by privatepay_challenge or privatepay_checkout; do not substitute a guessed amount or recipient. |
| Name | Required | Description |
|---|---|---|
| valid | No | Whether the facilitator accepted the exact payment requirements. |
| status | No | Verification status or next action. |
| evidence | No | Redacted facilitator evidence. |
| request_id | No | Redacted PrivatePAY request identifier when available. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is partly covered. The description adds material context beyond that: it is 'fail-closed', uses a 'configured facilitator', returns 'redacted evidence', and explicitly does not spend funds. It stops short of describing failure modes or what redacted means concretely, so a 4 rather than 5.
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 tightly packed sentence with the action front-loaded, followed by workflow placement and safety posture. Every clause carries information; there is no filler.
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?
Rich structured metadata (full schema coverage, nested objects, annotations, output schema) covers return shape and safety, while the description supplies the workflow position and fail-closed/no-spend semantics. Nothing an agent needs in order to invoke it correctly 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 100% and each of the three required parameters is documented in the schema, including the constraint to pass the exact requirements rather than a guessed amount or recipient. The description reinforces this ('exact original requirements') but adds no format or syntax detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Verify) and resource (x402 v2 PrivatePAY payload via the configured facilitator) and pins the scope ('against the exact original requirements'). This is clearly separable from privatepay_settle and privatepay_status, which do different things in the same 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?
Explicitly places the tool in the workflow: call after privatepay_challenge or privatepay_checkout and before privatepay_settle, naming both alternatives by name. An agent needs no inference to decide ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate a business or product objective into the most relevant PrivateDAO capabilities and a practical next step.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Natural-language task the agent wants to accomplish. | |
| network | No | Optional target network constraint. |
| Name | Required | Description |
|---|---|---|
| note | No | Matching and next-step guidance. |
| task | No | The original business task. |
| matches | No | Ranked service manifests to inspect before requesting work. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds that the tool returns relevant capabilities and a practical next step, but because an output schema exists, this adds only modest behavioral context 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?
A single front-loaded sentence with no waste. It states the transformation and outcome efficiently.
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 (2 parameters, output schema present, rich annotations), and the description sufficiently conveys that it is a recommendation/advisor tool producing capabilities and a next step. It could more explicitly state that it does not execute actions or when to prefer it over concrete sibling tools, but the essentials are present.
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 fully documents the 'task' and optional 'network' parameters. The description adds no extra meaning about parameter syntax, format, or constraints, which is acceptable given the complete schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Translate') and resource ('PrivateDAO capabilities') and clearly frames the tool as an advisor that maps objectives to recommendations. It does not explicitly distinguish itself from siblings like get_workflow_guide or list_catalog, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a business or product objective needing capability mapping, but it gives no explicit when-to-use, when-not-to-use, or alternative tools. The agent must infer this is an entry point rather than a concrete operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm an authorized payment reference for a selected request and return the payment/execution result. Use this after create_paid_job and only with the exact returned quote; it may write payment state and never accepts a guessed amount.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| signature | Yes | Finalized Solana transaction signature. |
| Name | Required | Description |
|---|---|---|
| status | No | Payment endpoint status or next action. |
| receipt | No | Public receipt metadata after successful execution. |
| required | No | Required fields when the HTTP payment endpoint must be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the basic mutation profile is covered. The description adds valuable non-schema context: the exact-quote requirement and the warning that it 'never accepts a guessed amount', which guards against amount fabrication and goes beyond what the annotations 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?
Two sentences, purpose front-loaded in the first clause, followed by the sequencing and safety constraints. Minor redundancy between 'only with the exact returned quote' and 'never accepts a guessed amount', but generally tight.
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?
An output schema and annotations are present, so return-format and safety details need not be re-explained. However, for a destructive payment mutation in a crowded payment/verification sibling set, the description should clarify how it differs from privatepay_settle, privatepay_job_payment, and verify_receipt; that gap leaves the agent to infer routing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: signature is described in the schema, but job_id has only a name and pattern regex. The description adds no meaning to job_id (e.g. that it must be the job from the prior call) and references 'the exact returned quote' even though no quote parameter exists, which could mislead about the actual inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Confirm' plus resource 'an authorized payment reference for a selected request' is specific, and the description notes it returns the payment/execution result. It names create_paid_job as its predecessor, which helps orient the agent, but it does not differentiate itself from lookalike payment siblings such as privatepay_job_payment, privatepay_settle, or verify_receipt.
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?
Explicit sequencing ('Use this after create_paid_job') and a hard precondition ('only with the exact returned quote') give the agent clear when-to-use context. It stops short of stating when-not to use it or naming the closest alternative payment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an asset/record or retrieve and validate a PrivateDAO receipt. Returns structured evidence and hashes; it is free and read-only, never pays or executes work, and replaces the separate basic, receipt, and get-receipt paths.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | No | Solana mint for basic verification. | |
| mode | No | Use basic for an asset/record check or receipt for an existing receipt. | receipt |
| asset | No | Alias for mint. | |
| record | No | Structured record for basic verification. | |
| network | No | Optional network identifier for the asset or receipt evidence. | |
| receipt | No | Receipt returned by a completed job. | |
| receipt_id | No | Receipt identifier to retrieve and verify. | |
| expected_hash | No | Optional result hash that must match the receipt evidence. | |
| expected_digest | No | Optional digest that must match the canonical verified record. |
| Name | Required | Description |
|---|---|---|
| status | No | Operation status. |
| receipt | No | Public receipt metadata when retrieved. |
| receipt_id | No | Public receipt identifier when available. |
| result_hash | No | Verified result hash when available. |
| evidence_hash | No | Canonical evidence hash when available. |
| verification_status | No | Verification result when evidence is accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely new context -- that the call is free, never pays or executes work, and returns structured evidence and hashes -- but says nothing about failure modes when expected_hash/expected_digest mismatch or what an invalid receipt yields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verification action, and the negative constraint ('never pays or executes work') is placed where it matters. The trailing clause about replacing legacy paths is useful but slightly compresses three ideas into one sentence.
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?
A 9-parameter, nested-object, multi-mode tool with an output schema; the description conveys the mode split and the read-only/no-payment guarantee, which is the key disambiguation. Missing is how the mutually exclusive inputs (receipt_id vs receipt vs mint vs asset vs record) interact, which the anyOf schema implies but never states plainly.
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% and each of the 9 parameters is documented in the schema, so the baseline applies. The description's 'asset/record' versus 'receipt' phrasing mirrors the mode enum without adding syntax, precedence rules, or semantics for expected_hash/expected_digest beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource set ('Verify an asset/record or retrieve and validate a PrivateDAO receipt') and explicitly says it consolidates the old basic/receipt/get-receipt paths. It does not, however, address how it differs from the sibling privatepay_verify, which an agent could easily confuse with 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?
Explicitly directs the agent to use this 'instead of separate basic, receipt, and get-receipt tools' and the schema mode enum distinguishes the two flows. It offers no when-not-to-use guidance or pointers to the privatepay_* verification siblings, so routing between them is left to inference.
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.
create_paid_job3 fields changedInput schema / descriptionAdded value: +"Create a selected paid service request and return either an immediate result or an exact quote-first payment intent. This call does not spend funds; use the returned quote with the matching payment tool."Input schema / properties / input / descriptionPrevious value: -"Service-specific JSON input."New value: +"Service-specific JSON input matching the selected service schema."Input schema / properties / service_id / descriptionAdded value: +"Paid service identifier selected from list_catalog or discover_agents."get_provider_integrations1 field changedOutput schema / propertiesAdded value: +{
+ "disclosure": {
+ "description": "Boundary explaining what the integration records do and do not prove.",
+ "type": "string"
+ },
+ "integrations": {
+ "description": "Provider and ecosystem integration records.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "provider_status": {
+ "description": "Public readiness signals with secrets removed.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+}job_status2 fields changedInput schema / descriptionAdded value: +"Read the current asynchronous request state, exact payment intent, result, or receipt reference. This is free and never retries or charges a payment."Input schema / properties / job_id / descriptionAdded value: +"Job identifier returned by create_paid_job; polling never retries or charges payment."privatepay_challenge7 fields changedInput schema / descriptionPrevious value: -"Create a structured PrivatePAY x402 V2 payment challenge for an eligible commercial workflow."New value: +"Create a fresh PrivatePAY x402 v2 challenge after checking rail status. This returns payment requirements and the PDAO private-settlement rule; it does not sign, broadcast, or move funds."Input schema / properties / amount_base_units / descriptionAdded value: +"Quoted USDC amount in token base units, not a decimal display amount."Input schema / properties / mime_type / descriptionAdded value: +"Optional response media type for the purchased resource."Input schema / properties / nonce / descriptionAdded value: +"Optional caller nonce used to bind a fresh challenge."Input schema / properties / provider_id / descriptionAdded value: +"PrivatePAY provider or merchant identifier."Input schema / properties / resource / descriptionAdded value: +"Stable HTTPS resource or service identifier being purchased."Output schema / propertiesAdded value: +{
+ "payment_required": {
+ "additionalProperties": true,
+ "description": "Exact x402 v2 requirements to present to the payer.",
+ "type": "object"
+ },
+ "payment_required_header": {
+ "description": "HTTP PAYMENT-REQUIRED value when returned by the checkout flow.",
+ "type": "string"
+ },
+ "privacy": {
+ "additionalProperties": true,
+ "description": "Redacted privacy boundary for the challenge.",
+ "type": "object"
+ },
+ "request_id": {
+ "description": "Fresh challenge or payment request identifier.",
+ "type": "string"
+ }
+}privatepay_checkout10 fields changedInput schema / descriptionPrevious value: -"Create an official MagicBlock private checkout or request its x402 challenge. No wallet signing or broadcasting occurs."New value: +"Create a MagicBlock PrivatePAY checkout or request its x402 payment-required challenge. This is a quote and preparation step: it never signs, broadcasts, or moves funds."Input schema / properties / amount_base_units / descriptionAdded value: +"Quoted USDC amount in base units."Input schema / properties / description / descriptionAdded value: +"Human-readable commercial description shown in the checkout response."Input schema / properties / expires_in_seconds / descriptionAdded value: +"Challenge lifetime in seconds, between one minute and one day."Input schema / properties / external_reference / descriptionAdded value: +"Merchant-owned idempotency or order reference."Input schema / properties / payer / descriptionAdded value: +"Solana payer wallet public key; never a private key."Input schema / properties / payment_id / descriptionAdded value: +"Existing 64-character checkout identifier when phase is challenge."Input schema / properties / phase / descriptionAdded value: +"Use create for a new checkout or challenge to request the payment-required response for an existing payment_id."Input schema / properties / resource / descriptionAdded value: +"HTTPS resource or service endpoint being purchased."Output schema / propertiesAdded value: +{
+ "payment_id": {
+ "description": "Checkout identifier used to request the challenge or continue the checkout.",
+ "type": "string"
+ },
+ "payment_required": {
+ "additionalProperties": true,
+ "description": "Exact x402 v2 requirements when the challenge phase is requested.",
+ "type": "object"
+ },
+ "payment_required_header": {
+ "description": "HTTP PAYMENT-REQUIRED value when returned.",
+ "type": "string"
+ },
+ "status": {
+ "description": "Checkout state or next action.",
+ "type": "string"
+ }
+}privatepay_job_payment2 fields changedInput schema / properties / job_id / descriptionAdded value: +"Job identifier returned by create_paid_job."Output schema / propertiesAdded value: +{
+ "job_id": {
+ "description": "Paid workflow job identifier.",
+ "type": "string"
+ },
+ "receipt": {
+ "additionalProperties": true,
+ "description": "Public evidence receipt when execution completes.",
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Service result when execution completes.",
+ "type": "object"
+ },
+ "status": {
+ "description": "Job or payment state after applying the supplied x402 proof.",
+ "type": "string"
+ }
+}privatepay_prepare9 fields changedInput schema / descriptionPrevious value: -"Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for local wallet signing. This does not sign or broadcast."New value: +"Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for local wallet inspection and signing. PrivateDAO never receives a private key and this tool never broadcasts."Input schema / properties / amount_base_units / descriptionAdded value: +"Token amount in base units."Input schema / properties / gasless / descriptionAdded value: +"Request the configured sponsored route when supported; the wallet still signs the returned transaction."Input schema / properties / owner / descriptionAdded value: +"Optional destination or balance owner public key."Input schema / properties / payer / descriptionAdded value: +"Wallet public key that will inspect and authorize the transaction."Input schema / properties / phase / descriptionAdded value: +"Unsigned wallet operation to prepare after the challenge: deposit into the private rail, private transfer, or withdrawal."Input schema / properties / request_id / descriptionAdded value: +"PrivatePAY request identifier returned by the challenge or checkout."Input schema / properties / split / descriptionAdded value: +"Optional private transfer split count, from one to fifteen."Output schema / propertiesAdded value: +{
+ "phase": {
+ "description": "Prepared private-rail operation.",
+ "enum": [
+ "deposit",
+ "transfer",
+ "withdraw"
+ ],
+ "type": "string"
+ },
+ "request_id": {
+ "description": "PrivatePAY request identifier bound to the unsigned operation.",
+ "type": "string"
+ },
+ "required_signers": {
+ "description": "Wallet public keys that must sign locally.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "transaction": {
+ "description": "Serialized unsigned transaction when the provider returns one.",
+ "type": "string"
+ }
+}privatepay_settle5 fields changedInput schema / descriptionPrevious value: -"Request x402 v2 PrivatePAY settlement through the configured payment workflow and return structured settlement evidence."New value: +"Settle an already authorized x402 v2 PrivatePAY payload through the configured facilitator and return redacted settlement evidence. Call privatepay_verify first; this is the only payment-moving PrivatePAY tool and may create a facilitator or on-chain settlement."Input schema / properties / paymentPayload / descriptionAdded value: +"The same finalized payer payload that passed privatepay_verify."Input schema / properties / paymentRequirements / descriptionAdded value: +"The unchanged requirements from the original PrivatePAY challenge."Input schema / properties / x402Version / descriptionAdded value: +"Must be x402 protocol version 2."Output schema / propertiesAdded value: +{
+ "evidence": {
+ "additionalProperties": true,
+ "description": "Redacted settlement evidence; provider secrets and sensitive payment payloads are excluded.",
+ "type": "object"
+ },
+ "request_id": {
+ "description": "Redacted PrivatePAY request identifier when available.",
+ "type": "string"
+ },
+ "settled": {
+ "description": "Whether the facilitator accepted settlement.",
+ "type": "boolean"
+ },
+ "status": {
+ "description": "Settlement status.",
+ "type": "string"
+ }
+}privatepay_status2 fields changedInput schema / descriptionPrevious value: -"Return the fail-closed readiness and privacy boundaries for PrivatePAY x402."New value: +"Read the current PrivatePAY x402 readiness, MagicBlock private-rail configuration, facilitator state, PDAO entry requirement, and public-chain privacy boundary. Use this first; it never creates a challenge or payment."Output schema / propertiesAdded value: +{
+ "activation_blockers": {
+ "description": "Explicit blockers when the rail is unavailable.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "enabled": {
+ "description": "Whether the private settlement rail is currently enabled for new payment operations.",
+ "type": "boolean"
+ },
+ "network": {
+ "description": "Settlement network identifier.",
+ "type": "string"
+ },
+ "pdao_required": {
+ "description": "Whether the private path requires the PDAO entry policy.",
+ "type": "boolean"
+ },
+ "privacy": {
+ "additionalProperties": true,
+ "description": "Provider-visible and public-chain privacy boundaries.",
+ "type": "object"
+ },
+ "settlement_mode": {
+ "description": "Configured provider settlement mode.",
+ "type": "string"
+ }
+}privatepay_verify5 fields changedInput schema / descriptionPrevious value: -"Validate an x402 v2 PrivatePAY payload against the agreed commercial requirements and return structured payment evidence."New value: +"Verify an x402 v2 PrivatePAY payload against the exact challenge requirements through the configured facilitator. This is read-only, fail-closed, and returns redacted structured evidence; call it before privatepay_settle."Input schema / properties / paymentPayload / descriptionAdded value: +"The payer wallet's finalized x402 payment payload, including the accepted scheme and transaction proof."Input schema / properties / paymentRequirements / descriptionAdded value: +"The exact requirements returned by privatepay_challenge or privatepay_checkout; do not substitute a guessed amount or recipient."Input schema / properties / x402Version / descriptionAdded value: +"Must be x402 protocol version 2."Output schema / propertiesAdded value: +{
+ "evidence": {
+ "additionalProperties": true,
+ "description": "Redacted facilitator evidence.",
+ "type": "object"
+ },
+ "request_id": {
+ "description": "Redacted PrivatePAY request identifier when available.",
+ "type": "string"
+ },
+ "status": {
+ "description": "Verification status or next action.",
+ "type": "string"
+ },
+ "valid": {
+ "description": "Whether the facilitator accepted the exact payment requirements.",
+ "type": "boolean"
+ }
+}service_recommendationcreate_paid_job3 fields changedInput schema / descriptionRemoved value: -"Create a selected paid service request and return either an immediate result or an exact quote-first payment intent. This call does not spend funds; use the returned quote with the matching payment tool."Input schema / properties / input / descriptionPrevious value: -"Service-specific JSON input matching the selected service schema."New value: +"Service-specific JSON input."Input schema / properties / service_id / descriptionRemoved value: -"Paid service identifier selected from list_catalog or discover_agents."get_provider_integrations1 field changedOutput schema / propertiesRemoved value: -{
- "disclosure": {
- "description": "Boundary explaining what the integration records do and do not prove.",
- "type": "string"
- },
- "integrations": {
- "description": "Provider and ecosystem integration records.",
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "type": "array"
- },
- "provider_status": {
- "description": "Public readiness signals with secrets removed.",
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "type": "array"
- }
-}job_status2 fields changedInput schema / descriptionRemoved value: -"Read the current asynchronous request state, exact payment intent, result, or receipt reference. This is free and never retries or charges a payment."Input schema / properties / job_id / descriptionRemoved value: -"Job identifier returned by create_paid_job; polling never retries or charges payment."privatepay_challenge7 fields changedInput schema / descriptionPrevious value: -"Create a fresh PrivatePAY x402 v2 challenge after checking rail status. This returns payment requirements and the PDAO private-settlement rule; it does not sign, broadcast, or move funds."New value: +"Create a structured PrivatePAY x402 V2 payment challenge for an eligible commercial workflow."Input schema / properties / amount_base_units / descriptionRemoved value: -"Quoted USDC amount in token base units, not a decimal display amount."Input schema / properties / mime_type / descriptionRemoved value: -"Optional response media type for the purchased resource."Input schema / properties / nonce / descriptionRemoved value: -"Optional caller nonce used to bind a fresh challenge."Input schema / properties / provider_id / descriptionRemoved value: -"PrivatePAY provider or merchant identifier."Input schema / properties / resource / descriptionRemoved value: -"Stable HTTPS resource or service identifier being purchased."Output schema / propertiesRemoved value: -{
- "payment_required": {
- "additionalProperties": true,
- "description": "Exact x402 v2 requirements to present to the payer.",
- "type": "object"
- },
- "payment_required_header": {
- "description": "HTTP PAYMENT-REQUIRED value when returned by the checkout flow.",
- "type": "string"
- },
- "privacy": {
- "additionalProperties": true,
- "description": "Redacted privacy boundary for the challenge.",
- "type": "object"
- },
- "request_id": {
- "description": "Fresh challenge or payment request identifier.",
- "type": "string"
- }
-}privatepay_checkout10 fields changedInput schema / descriptionPrevious value: -"Create a MagicBlock PrivatePAY checkout or request its x402 payment-required challenge. This is a quote and preparation step: it never signs, broadcasts, or moves funds."New value: +"Create an official MagicBlock private checkout or request its x402 challenge. No wallet signing or broadcasting occurs."Input schema / properties / amount_base_units / descriptionRemoved value: -"Quoted USDC amount in base units."Input schema / properties / description / descriptionRemoved value: -"Human-readable commercial description shown in the checkout response."Input schema / properties / expires_in_seconds / descriptionRemoved value: -"Challenge lifetime in seconds, between one minute and one day."Input schema / properties / external_reference / descriptionRemoved value: -"Merchant-owned idempotency or order reference."Input schema / properties / payer / descriptionRemoved value: -"Solana payer wallet public key; never a private key."Input schema / properties / payment_id / descriptionRemoved value: -"Existing 64-character checkout identifier when phase is challenge."Input schema / properties / phase / descriptionRemoved value: -"Use create for a new checkout or challenge to request the payment-required response for an existing payment_id."Input schema / properties / resource / descriptionRemoved value: -"HTTPS resource or service endpoint being purchased."Output schema / propertiesRemoved value: -{
- "payment_id": {
- "description": "Checkout identifier used to request the challenge or continue the checkout.",
- "type": "string"
- },
- "payment_required": {
- "additionalProperties": true,
- "description": "Exact x402 v2 requirements when the challenge phase is requested.",
- "type": "object"
- },
- "payment_required_header": {
- "description": "HTTP PAYMENT-REQUIRED value when returned.",
- "type": "string"
- },
- "status": {
- "description": "Checkout state or next action.",
- "type": "string"
- }
-}privatepay_job_payment2 fields changedInput schema / properties / job_id / descriptionRemoved value: -"Job identifier returned by create_paid_job."Output schema / propertiesRemoved value: -{
- "job_id": {
- "description": "Paid workflow job identifier.",
- "type": "string"
- },
- "receipt": {
- "additionalProperties": true,
- "description": "Public evidence receipt when execution completes.",
- "type": "object"
- },
- "result": {
- "additionalProperties": true,
- "description": "Service result when execution completes.",
- "type": "object"
- },
- "status": {
- "description": "Job or payment state after applying the supplied x402 proof.",
- "type": "string"
- }
-}privatepay_prepare9 fields changedInput schema / descriptionPrevious value: -"Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for local wallet inspection and signing. PrivateDAO never receives a private key and this tool never broadcasts."New value: +"Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for local wallet signing. This does not sign or broadcast."Input schema / properties / amount_base_units / descriptionRemoved value: -"Token amount in base units."Input schema / properties / gasless / descriptionRemoved value: -"Request the configured sponsored route when supported; the wallet still signs the returned transaction."Input schema / properties / owner / descriptionRemoved value: -"Optional destination or balance owner public key."Input schema / properties / payer / descriptionRemoved value: -"Wallet public key that will inspect and authorize the transaction."Input schema / properties / phase / descriptionRemoved value: -"Unsigned wallet operation to prepare after the challenge: deposit into the private rail, private transfer, or withdrawal."Input schema / properties / request_id / descriptionRemoved value: -"PrivatePAY request identifier returned by the challenge or checkout."Input schema / properties / split / descriptionRemoved value: -"Optional private transfer split count, from one to fifteen."Output schema / propertiesRemoved value: -{
- "phase": {
- "description": "Prepared private-rail operation.",
- "enum": [
- "deposit",
- "transfer",
- "withdraw"
- ],
- "type": "string"
- },
- "request_id": {
- "description": "PrivatePAY request identifier bound to the unsigned operation.",
- "type": "string"
- },
- "required_signers": {
- "description": "Wallet public keys that must sign locally.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "transaction": {
- "description": "Serialized unsigned transaction when the provider returns one.",
- "type": "string"
- }
-}privatepay_settle5 fields changedInput schema / descriptionPrevious value: -"Settle an already authorized x402 v2 PrivatePAY payload through the configured facilitator and return redacted settlement evidence. Call privatepay_verify first; this is the only payment-moving PrivatePAY tool and may create a facilitator or on-chain settlement."New value: +"Request x402 v2 PrivatePAY settlement through the configured payment workflow and return structured settlement evidence."Input schema / properties / paymentPayload / descriptionRemoved value: -"The same finalized payer payload that passed privatepay_verify."Input schema / properties / paymentRequirements / descriptionRemoved value: -"The unchanged requirements from the original PrivatePAY challenge."Input schema / properties / x402Version / descriptionRemoved value: -"Must be x402 protocol version 2."Output schema / propertiesRemoved value: -{
- "evidence": {
- "additionalProperties": true,
- "description": "Redacted settlement evidence; provider secrets and sensitive payment payloads are excluded.",
- "type": "object"
- },
- "request_id": {
- "description": "Redacted PrivatePAY request identifier when available.",
- "type": "string"
- },
- "settled": {
- "description": "Whether the facilitator accepted settlement.",
- "type": "boolean"
- },
- "status": {
- "description": "Settlement status.",
- "type": "string"
- }
-}privatepay_status2 fields changedInput schema / descriptionPrevious value: -"Read the current PrivatePAY x402 readiness, MagicBlock private-rail configuration, facilitator state, PDAO entry requirement, and public-chain privacy boundary. Use this first; it never creates a challenge or payment."New value: +"Return the fail-closed readiness and privacy boundaries for PrivatePAY x402."Output schema / propertiesRemoved value: -{
- "activation_blockers": {
- "description": "Explicit blockers when the rail is unavailable.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "enabled": {
- "description": "Whether the private settlement rail is currently enabled for new payment operations.",
- "type": "boolean"
- },
- "network": {
- "description": "Settlement network identifier.",
- "type": "string"
- },
- "pdao_required": {
- "description": "Whether the private path requires the PDAO entry policy.",
- "type": "boolean"
- },
- "privacy": {
- "additionalProperties": true,
- "description": "Provider-visible and public-chain privacy boundaries.",
- "type": "object"
- },
- "settlement_mode": {
- "description": "Configured provider settlement mode.",
- "type": "string"
- }
-}privatepay_verify5 fields changedInput schema / descriptionPrevious value: -"Verify an x402 v2 PrivatePAY payload against the exact challenge requirements through the configured facilitator. This is read-only, fail-closed, and returns redacted structured evidence; call it before privatepay_settle."New value: +"Validate an x402 v2 PrivatePAY payload against the agreed commercial requirements and return structured payment evidence."Input schema / properties / paymentPayload / descriptionRemoved value: -"The payer wallet's finalized x402 payment payload, including the accepted scheme and transaction proof."Input schema / properties / paymentRequirements / descriptionRemoved value: -"The exact requirements returned by privatepay_challenge or privatepay_checkout; do not substitute a guessed amount or recipient."Input schema / properties / x402Version / descriptionRemoved value: -"Must be x402 protocol version 2."Output schema / propertiesRemoved value: -{
- "evidence": {
- "additionalProperties": true,
- "description": "Redacted facilitator evidence.",
- "type": "object"
- },
- "request_id": {
- "description": "Redacted PrivatePAY request identifier when available.",
- "type": "string"
- },
- "status": {
- "description": "Verification status or next action.",
- "type": "string"
- },
- "valid": {
- "description": "Whether the facilitator accepted the exact payment requirements.",
- "type": "boolean"
- }
-}service_recommendationcreate_paid_job3 fields changedInput schema / descriptionAdded value: +"Create a selected paid service request and return either an immediate result or an exact quote-first payment intent. This call does not spend funds; use the returned quote with the matching payment tool."Input schema / properties / input / descriptionPrevious value: -"Service-specific JSON input."New value: +"Service-specific JSON input matching the selected service schema."Input schema / properties / service_id / descriptionAdded value: +"Paid service identifier selected from list_catalog or discover_agents."get_provider_integrations1 field changedOutput schema / propertiesAdded value: +{
+ "disclosure": {
+ "description": "Boundary explaining what the integration records do and do not prove.",
+ "type": "string"
+ },
+ "integrations": {
+ "description": "Provider and ecosystem integration records.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "provider_status": {
+ "description": "Public readiness signals with secrets removed.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+}job_status2 fields changedInput schema / descriptionAdded value: +"Read the current asynchronous request state, exact payment intent, result, or receipt reference. This is free and never retries or charges a payment."Input schema / properties / job_id / descriptionAdded value: +"Job identifier returned by create_paid_job; polling never retries or charges payment."privatepay_challenge7 fields changedInput schema / descriptionPrevious value: -"Create a structured PrivatePAY x402 V2 payment challenge for an eligible commercial workflow."New value: +"Create a fresh PrivatePAY x402 v2 challenge after checking rail status. This returns payment requirements and the PDAO private-settlement rule; it does not sign, broadcast, or move funds."Input schema / properties / amount_base_units / descriptionAdded value: +"Quoted USDC amount in token base units, not a decimal display amount."Input schema / properties / mime_type / descriptionAdded value: +"Optional response media type for the purchased resource."Input schema / properties / nonce / descriptionAdded value: +"Optional caller nonce used to bind a fresh challenge."Input schema / properties / provider_id / descriptionAdded value: +"PrivatePAY provider or merchant identifier."Input schema / properties / resource / descriptionAdded value: +"Stable HTTPS resource or service identifier being purchased."Output schema / propertiesAdded value: +{
+ "payment_required": {
+ "additionalProperties": true,
+ "description": "Exact x402 v2 requirements to present to the payer.",
+ "type": "object"
+ },
+ "payment_required_header": {
+ "description": "HTTP PAYMENT-REQUIRED value when returned by the checkout flow.",
+ "type": "string"
+ },
+ "privacy": {
+ "additionalProperties": true,
+ "description": "Redacted privacy boundary for the challenge.",
+ "type": "object"
+ },
+ "request_id": {
+ "description": "Fresh challenge or payment request identifier.",
+ "type": "string"
+ }
+}privatepay_checkout10 fields changedInput schema / descriptionPrevious value: -"Create an official MagicBlock private checkout or request its x402 challenge. No wallet signing or broadcasting occurs."New value: +"Create a MagicBlock PrivatePAY checkout or request its x402 payment-required challenge. This is a quote and preparation step: it never signs, broadcasts, or moves funds."Input schema / properties / amount_base_units / descriptionAdded value: +"Quoted USDC amount in base units."Input schema / properties / description / descriptionAdded value: +"Human-readable commercial description shown in the checkout response."Input schema / properties / expires_in_seconds / descriptionAdded value: +"Challenge lifetime in seconds, between one minute and one day."Input schema / properties / external_reference / descriptionAdded value: +"Merchant-owned idempotency or order reference."Input schema / properties / payer / descriptionAdded value: +"Solana payer wallet public key; never a private key."Input schema / properties / payment_id / descriptionAdded value: +"Existing 64-character checkout identifier when phase is challenge."Input schema / properties / phase / descriptionAdded value: +"Use create for a new checkout or challenge to request the payment-required response for an existing payment_id."Input schema / properties / resource / descriptionAdded value: +"HTTPS resource or service endpoint being purchased."Output schema / propertiesAdded value: +{
+ "payment_id": {
+ "description": "Checkout identifier used to request the challenge or continue the checkout.",
+ "type": "string"
+ },
+ "payment_required": {
+ "additionalProperties": true,
+ "description": "Exact x402 v2 requirements when the challenge phase is requested.",
+ "type": "object"
+ },
+ "payment_required_header": {
+ "description": "HTTP PAYMENT-REQUIRED value when returned.",
+ "type": "string"
+ },
+ "status": {
+ "description": "Checkout state or next action.",
+ "type": "string"
+ }
+}privatepay_job_payment2 fields changedInput schema / properties / job_id / descriptionAdded value: +"Job identifier returned by create_paid_job."Output schema / propertiesAdded value: +{
+ "job_id": {
+ "description": "Paid workflow job identifier.",
+ "type": "string"
+ },
+ "receipt": {
+ "additionalProperties": true,
+ "description": "Public evidence receipt when execution completes.",
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Service result when execution completes.",
+ "type": "object"
+ },
+ "status": {
+ "description": "Job or payment state after applying the supplied x402 proof.",
+ "type": "string"
+ }
+}privatepay_prepare9 fields changedInput schema / descriptionPrevious value: -"Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for local wallet signing. This does not sign or broadcast."New value: +"Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for local wallet inspection and signing. PrivateDAO never receives a private key and this tool never broadcasts."Input schema / properties / amount_base_units / descriptionAdded value: +"Token amount in base units."Input schema / properties / gasless / descriptionAdded value: +"Request the configured sponsored route when supported; the wallet still signs the returned transaction."Input schema / properties / owner / descriptionAdded value: +"Optional destination or balance owner public key."Input schema / properties / payer / descriptionAdded value: +"Wallet public key that will inspect and authorize the transaction."Input schema / properties / phase / descriptionAdded value: +"Unsigned wallet operation to prepare after the challenge: deposit into the private rail, private transfer, or withdrawal."Input schema / properties / request_id / descriptionAdded value: +"PrivatePAY request identifier returned by the challenge or checkout."Input schema / properties / split / descriptionAdded value: +"Optional private transfer split count, from one to fifteen."Output schema / propertiesAdded value: +{
+ "phase": {
+ "description": "Prepared private-rail operation.",
+ "enum": [
+ "deposit",
+ "transfer",
+ "withdraw"
+ ],
+ "type": "string"
+ },
+ "request_id": {
+ "description": "PrivatePAY request identifier bound to the unsigned operation.",
+ "type": "string"
+ },
+ "required_signers": {
+ "description": "Wallet public keys that must sign locally.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "transaction": {
+ "description": "Serialized unsigned transaction when the provider returns one.",
+ "type": "string"
+ }
+}privatepay_settle5 fields changedInput schema / descriptionPrevious value: -"Request x402 v2 PrivatePAY settlement through the configured payment workflow and return structured settlement evidence."New value: +"Settle an already authorized x402 v2 PrivatePAY payload through the configured facilitator and return redacted settlement evidence. Call privatepay_verify first; this is the only payment-moving PrivatePAY tool and may create a facilitator or on-chain settlement."Input schema / properties / paymentPayload / descriptionAdded value: +"The same finalized payer payload that passed privatepay_verify."Input schema / properties / paymentRequirements / descriptionAdded value: +"The unchanged requirements from the original PrivatePAY challenge."Input schema / properties / x402Version / descriptionAdded value: +"Must be x402 protocol version 2."Output schema / propertiesAdded value: +{
+ "evidence": {
+ "additionalProperties": true,
+ "description": "Redacted settlement evidence; provider secrets and sensitive payment payloads are excluded.",
+ "type": "object"
+ },
+ "request_id": {
+ "description": "Redacted PrivatePAY request identifier when available.",
+ "type": "string"
+ },
+ "settled": {
+ "description": "Whether the facilitator accepted settlement.",
+ "type": "boolean"
+ },
+ "status": {
+ "description": "Settlement status.",
+ "type": "string"
+ }
+}privatepay_status2 fields changedInput schema / descriptionPrevious value: -"Return the fail-closed readiness and privacy boundaries for PrivatePAY x402."New value: +"Read the current PrivatePAY x402 readiness, MagicBlock private-rail configuration, facilitator state, PDAO entry requirement, and public-chain privacy boundary. Use this first; it never creates a challenge or payment."Output schema / propertiesAdded value: +{
+ "activation_blockers": {
+ "description": "Explicit blockers when the rail is unavailable.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "enabled": {
+ "description": "Whether the private settlement rail is currently enabled for new payment operations.",
+ "type": "boolean"
+ },
+ "network": {
+ "description": "Settlement network identifier.",
+ "type": "string"
+ },
+ "pdao_required": {
+ "description": "Whether the private path requires the PDAO entry policy.",
+ "type": "boolean"
+ },
+ "privacy": {
+ "additionalProperties": true,
+ "description": "Provider-visible and public-chain privacy boundaries.",
+ "type": "object"
+ },
+ "settlement_mode": {
+ "description": "Configured provider settlement mode.",
+ "type": "string"
+ }
+}privatepay_verify5 fields changedInput schema / descriptionPrevious value: -"Validate an x402 v2 PrivatePAY payload against the agreed commercial requirements and return structured payment evidence."New value: +"Verify an x402 v2 PrivatePAY payload against the exact challenge requirements through the configured facilitator. This is read-only, fail-closed, and returns redacted structured evidence; call it before privatepay_settle."Input schema / properties / paymentPayload / descriptionAdded value: +"The payer wallet's finalized x402 payment payload, including the accepted scheme and transaction proof."Input schema / properties / paymentRequirements / descriptionAdded value: +"The exact requirements returned by privatepay_challenge or privatepay_checkout; do not substitute a guessed amount or recipient."Input schema / properties / x402Version / descriptionAdded value: +"Must be x402 protocol version 2."Output schema / propertiesAdded value: +{
+ "evidence": {
+ "additionalProperties": true,
+ "description": "Redacted facilitator evidence.",
+ "type": "object"
+ },
+ "request_id": {
+ "description": "Redacted PrivatePAY request identifier when available.",
+ "type": "string"
+ },
+ "status": {
+ "description": "Verification status or next action.",
+ "type": "string"
+ },
+ "valid": {
+ "description": "Whether the facilitator accepted the exact payment requirements.",
+ "type": "boolean"
+ }
+}service_recommendationcreate_paid_job3 fields changedInput schema / descriptionRemoved value: -"Create a selected paid service request and return either an immediate result or an exact quote-first payment intent. This call does not spend funds; use the returned quote with the matching payment tool."Input schema / properties / input / descriptionPrevious value: -"Service-specific JSON input matching the selected service schema."New value: +"Service-specific JSON input."Input schema / properties / service_id / descriptionRemoved value: -"Paid service identifier selected from list_catalog or discover_agents."get_provider_integrations1 field changedOutput schema / propertiesRemoved value: -{
- "disclosure": {
- "description": "Boundary explaining what the integration records do and do not prove.",
- "type": "string"
- },
- "integrations": {
- "description": "Provider and ecosystem integration records.",
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "type": "array"
- },
- "provider_status": {
- "description": "Public readiness signals with secrets removed.",
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "type": "array"
- }
-}job_status2 fields changedInput schema / descriptionRemoved value: -"Read the current asynchronous request state, exact payment intent, result, or receipt reference. This is free and never retries or charges a payment."Input schema / properties / job_id / descriptionRemoved value: -"Job identifier returned by create_paid_job; polling never retries or charges payment."privatepay_challenge7 fields changedInput schema / descriptionPrevious value: -"Create a fresh PrivatePAY x402 v2 challenge after checking rail status. This returns payment requirements and the PDAO private-settlement rule; it does not sign, broadcast, or move funds."New value: +"Create a structured PrivatePAY x402 V2 payment challenge for an eligible commercial workflow."Input schema / properties / amount_base_units / descriptionRemoved value: -"Quoted USDC amount in token base units, not a decimal display amount."Input schema / properties / mime_type / descriptionRemoved value: -"Optional response media type for the purchased resource."Input schema / properties / nonce / descriptionRemoved value: -"Optional caller nonce used to bind a fresh challenge."Input schema / properties / provider_id / descriptionRemoved value: -"PrivatePAY provider or merchant identifier."Input schema / properties / resource / descriptionRemoved value: -"Stable HTTPS resource or service identifier being purchased."Output schema / propertiesRemoved value: -{
- "payment_required": {
- "additionalProperties": true,
- "description": "Exact x402 v2 requirements to present to the payer.",
- "type": "object"
- },
- "payment_required_header": {
- "description": "HTTP PAYMENT-REQUIRED value when returned by the checkout flow.",
- "type": "string"
- },
- "privacy": {
- "additionalProperties": true,
- "description": "Redacted privacy boundary for the challenge.",
- "type": "object"
- },
- "request_id": {
- "description": "Fresh challenge or payment request identifier.",
- "type": "string"
- }
-}privatepay_checkout10 fields changedInput schema / descriptionPrevious value: -"Create a MagicBlock PrivatePAY checkout or request its x402 payment-required challenge. This is a quote and preparation step: it never signs, broadcasts, or moves funds."New value: +"Create an official MagicBlock private checkout or request its x402 challenge. No wallet signing or broadcasting occurs."Input schema / properties / amount_base_units / descriptionRemoved value: -"Quoted USDC amount in base units."Input schema / properties / description / descriptionRemoved value: -"Human-readable commercial description shown in the checkout response."Input schema / properties / expires_in_seconds / descriptionRemoved value: -"Challenge lifetime in seconds, between one minute and one day."Input schema / properties / external_reference / descriptionRemoved value: -"Merchant-owned idempotency or order reference."Input schema / properties / payer / descriptionRemoved value: -"Solana payer wallet public key; never a private key."Input schema / properties / payment_id / descriptionRemoved value: -"Existing 64-character checkout identifier when phase is challenge."Input schema / properties / phase / descriptionRemoved value: -"Use create for a new checkout or challenge to request the payment-required response for an existing payment_id."Input schema / properties / resource / descriptionRemoved value: -"HTTPS resource or service endpoint being purchased."Output schema / propertiesRemoved value: -{
- "payment_id": {
- "description": "Checkout identifier used to request the challenge or continue the checkout.",
- "type": "string"
- },
- "payment_required": {
- "additionalProperties": true,
- "description": "Exact x402 v2 requirements when the challenge phase is requested.",
- "type": "object"
- },
- "payment_required_header": {
- "description": "HTTP PAYMENT-REQUIRED value when returned.",
- "type": "string"
- },
- "status": {
- "description": "Checkout state or next action.",
- "type": "string"
- }
-}privatepay_job_payment2 fields changedInput schema / properties / job_id / descriptionRemoved value: -"Job identifier returned by create_paid_job."Output schema / propertiesRemoved value: -{
- "job_id": {
- "description": "Paid workflow job identifier.",
- "type": "string"
- },
- "receipt": {
- "additionalProperties": true,
- "description": "Public evidence receipt when execution completes.",
- "type": "object"
- },
- "result": {
- "additionalProperties": true,
- "description": "Service result when execution completes.",
- "type": "object"
- },
- "status": {
- "description": "Job or payment state after applying the supplied x402 proof.",
- "type": "string"
- }
-}privatepay_prepare9 fields changedInput schema / descriptionPrevious value: -"Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for local wallet inspection and signing. PrivateDAO never receives a private key and this tool never broadcasts."New value: +"Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for local wallet signing. This does not sign or broadcast."Input schema / properties / amount_base_units / descriptionRemoved value: -"Token amount in base units."Input schema / properties / gasless / descriptionRemoved value: -"Request the configured sponsored route when supported; the wallet still signs the returned transaction."Input schema / properties / owner / descriptionRemoved value: -"Optional destination or balance owner public key."Input schema / properties / payer / descriptionRemoved value: -"Wallet public key that will inspect and authorize the transaction."Input schema / properties / phase / descriptionRemoved value: -"Unsigned wallet operation to prepare after the challenge: deposit into the private rail, private transfer, or withdrawal."Input schema / properties / request_id / descriptionRemoved value: -"PrivatePAY request identifier returned by the challenge or checkout."Input schema / properties / split / descriptionRemoved value: -"Optional private transfer split count, from one to fifteen."Output schema / propertiesRemoved value: -{
- "phase": {
- "description": "Prepared private-rail operation.",
- "enum": [
- "deposit",
- "transfer",
- "withdraw"
- ],
- "type": "string"
- },
- "request_id": {
- "description": "PrivatePAY request identifier bound to the unsigned operation.",
- "type": "string"
- },
- "required_signers": {
- "description": "Wallet public keys that must sign locally.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "transaction": {
- "description": "Serialized unsigned transaction when the provider returns one.",
- "type": "string"
- }
-}privatepay_settle5 fields changedInput schema / descriptionPrevious value: -"Settle an already authorized x402 v2 PrivatePAY payload through the configured facilitator and return redacted settlement evidence. Call privatepay_verify first; this is the only payment-moving PrivatePAY tool and may create a facilitator or on-chain settlement."New value: +"Request x402 v2 PrivatePAY settlement through the configured payment workflow and return structured settlement evidence."Input schema / properties / paymentPayload / descriptionRemoved value: -"The same finalized payer payload that passed privatepay_verify."Input schema / properties / paymentRequirements / descriptionRemoved value: -"The unchanged requirements from the original PrivatePAY challenge."Input schema / properties / x402Version / descriptionRemoved value: -"Must be x402 protocol version 2."Output schema / propertiesRemoved value: -{
- "evidence": {
- "additionalProperties": true,
- "description": "Redacted settlement evidence; provider secrets and sensitive payment payloads are excluded.",
- "type": "object"
- },
- "request_id": {
- "description": "Redacted PrivatePAY request identifier when available.",
- "type": "string"
- },
- "settled": {
- "description": "Whether the facilitator accepted settlement.",
- "type": "boolean"
- },
- "status": {
- "description": "Settlement status.",
- "type": "string"
- }
-}privatepay_status2 fields changedInput schema / descriptionPrevious value: -"Read the current PrivatePAY x402 readiness, MagicBlock private-rail configuration, facilitator state, PDAO entry requirement, and public-chain privacy boundary. Use this first; it never creates a challenge or payment."New value: +"Return the fail-closed readiness and privacy boundaries for PrivatePAY x402."Output schema / propertiesRemoved value: -{
- "activation_blockers": {
- "description": "Explicit blockers when the rail is unavailable.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "enabled": {
- "description": "Whether the private settlement rail is currently enabled for new payment operations.",
- "type": "boolean"
- },
- "network": {
- "description": "Settlement network identifier.",
- "type": "string"
- },
- "pdao_required": {
- "description": "Whether the private path requires the PDAO entry policy.",
- "type": "boolean"
- },
- "privacy": {
- "additionalProperties": true,
- "description": "Provider-visible and public-chain privacy boundaries.",
- "type": "object"
- },
- "settlement_mode": {
- "description": "Configured provider settlement mode.",
- "type": "string"
- }
-}privatepay_verify5 fields changedInput schema / descriptionPrevious value: -"Verify an x402 v2 PrivatePAY payload against the exact challenge requirements through the configured facilitator. This is read-only, fail-closed, and returns redacted structured evidence; call it before privatepay_settle."New value: +"Validate an x402 v2 PrivatePAY payload against the agreed commercial requirements and return structured payment evidence."Input schema / properties / paymentPayload / descriptionRemoved value: -"The payer wallet's finalized x402 payment payload, including the accepted scheme and transaction proof."Input schema / properties / paymentRequirements / descriptionRemoved value: -"The exact requirements returned by privatepay_challenge or privatepay_checkout; do not substitute a guessed amount or recipient."Input schema / properties / x402Version / descriptionRemoved value: -"Must be x402 protocol version 2."Output schema / propertiesRemoved value: -{
- "evidence": {
- "additionalProperties": true,
- "description": "Redacted facilitator evidence.",
- "type": "object"
- },
- "request_id": {
- "description": "Redacted PrivatePAY request identifier when available.",
- "type": "string"
- },
- "status": {
- "description": "Verification status or next action.",
- "type": "string"
- },
- "valid": {
- "description": "Whether the facilitator accepted the exact payment requirements.",
- "type": "boolean"
- }
-}service_recommendationexchange_overviewexecution_guideget_provider_integrations1 field changedOutput schema / propertiesAdded value: +{
+ "disclosure": {
+ "description": "Boundary explaining what the integration records do and do not prove.",
+ "type": "string"
+ },
+ "integrations": {
+ "description": "Provider and ecosystem integration records.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "provider_status": {
+ "description": "Public readiness signals with secrets removed.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+}payment_guidepdao_servicesprivatepay_challenge1 field changedOutput schema / propertiesAdded value: +{
+ "payment_required": {
+ "additionalProperties": true,
+ "description": "Exact x402 v2 requirements to present to the payer.",
+ "type": "object"
+ },
+ "payment_required_header": {
+ "description": "HTTP PAYMENT-REQUIRED value when returned by the checkout flow.",
+ "type": "string"
+ },
+ "privacy": {
+ "additionalProperties": true,
+ "description": "Redacted privacy boundary for the challenge.",
+ "type": "object"
+ },
+ "request_id": {
+ "description": "Fresh challenge or payment request identifier.",
+ "type": "string"
+ }
+}privatepay_checkout1 field changedOutput schema / propertiesAdded value: +{
+ "payment_id": {
+ "description": "Checkout identifier used to request the challenge or continue the checkout.",
+ "type": "string"
+ },
+ "payment_required": {
+ "additionalProperties": true,
+ "description": "Exact x402 v2 requirements when the challenge phase is requested.",
+ "type": "object"
+ },
+ "payment_required_header": {
+ "description": "HTTP PAYMENT-REQUIRED value when returned.",
+ "type": "string"
+ },
+ "status": {
+ "description": "Checkout state or next action.",
+ "type": "string"
+ }
+}privatepay_job_payment1 field changedOutput schema / propertiesAdded value: +{
+ "job_id": {
+ "description": "Paid workflow job identifier.",
+ "type": "string"
+ },
+ "receipt": {
+ "additionalProperties": true,
+ "description": "Public evidence receipt when execution completes.",
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Service result when execution completes.",
+ "type": "object"
+ },
+ "status": {
+ "description": "Job or payment state after applying the supplied x402 proof.",
+ "type": "string"
+ }
+}privatepay_prepare1 field changedOutput schema / propertiesAdded value: +{
+ "phase": {
+ "description": "Prepared private-rail operation.",
+ "enum": [
+ "deposit",
+ "transfer",
+ "withdraw"
+ ],
+ "type": "string"
+ },
+ "request_id": {
+ "description": "PrivatePAY request identifier bound to the unsigned operation.",
+ "type": "string"
+ },
+ "required_signers": {
+ "description": "Wallet public keys that must sign locally.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "transaction": {
+ "description": "Serialized unsigned transaction when the provider returns one.",
+ "type": "string"
+ }
+}privatepay_settle1 field changedOutput schema / propertiesAdded value: +{
+ "evidence": {
+ "additionalProperties": true,
+ "description": "Redacted settlement evidence; provider secrets and sensitive payment payloads are excluded.",
+ "type": "object"
+ },
+ "request_id": {
+ "description": "Redacted PrivatePAY request identifier when available.",
+ "type": "string"
+ },
+ "settled": {
+ "description": "Whether the facilitator accepted settlement.",
+ "type": "boolean"
+ },
+ "status": {
+ "description": "Settlement status.",
+ "type": "string"
+ }
+}privatepay_status1 field changedOutput schema / propertiesAdded value: +{
+ "activation_blockers": {
+ "description": "Explicit blockers when the rail is unavailable.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "enabled": {
+ "description": "Whether the private settlement rail is currently enabled for new payment operations.",
+ "type": "boolean"
+ },
+ "network": {
+ "description": "Settlement network identifier.",
+ "type": "string"
+ },
+ "pdao_required": {
+ "description": "Whether the private path requires the PDAO entry policy.",
+ "type": "boolean"
+ },
+ "privacy": {
+ "additionalProperties": true,
+ "description": "Provider-visible and public-chain privacy boundaries.",
+ "type": "object"
+ },
+ "settlement_mode": {
+ "description": "Configured provider settlement mode.",
+ "type": "string"
+ }
+}privatepay_verify1 field changedOutput schema / propertiesAdded value: +{
+ "evidence": {
+ "additionalProperties": true,
+ "description": "Redacted facilitator evidence.",
+ "type": "object"
+ },
+ "request_id": {
+ "description": "Redacted PrivatePAY request identifier when available.",
+ "type": "string"
+ },
+ "status": {
+ "description": "Verification status or next action.",
+ "type": "string"
+ },
+ "valid": {
+ "description": "Whether the facilitator accepted the exact payment requirements.",
+ "type": "boolean"
+ }
+}product_catalogprovider_integrationsservice_recommendation2 fields changedOutput schema / descriptionPrevious value: -"Structured PrivateDAO tool response."New value: +"Ranked first-party service recommendations for the requested business task."Output schema / propertiesAdded value: +{
+ "matches": {
+ "description": "Ranked service manifests to inspect before requesting work.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "note": {
+ "description": "Matching and next-step guidance.",
+ "type": "string"
+ },
+ "task": {
+ "description": "The original business task.",
+ "type": "string"
+ }
+}exchange_overviewexecution_guidepayment_guidepdao_servicesproduct_catalogprovider_integrationsservice_recommendationcreate_paid_job3 fields changedInput schema / descriptionAdded value: +"Create a selected paid service request and return either an immediate result or an exact quote-first payment intent. This call does not spend funds; use the returned quote with the matching payment tool."Input schema / properties / input / descriptionPrevious value: -"Service-specific JSON input."New value: +"Service-specific JSON input matching the selected service schema."Input schema / properties / service_id / descriptionAdded value: +"Paid service identifier selected from list_catalog or discover_agents."job_status2 fields changedInput schema / descriptionAdded value: +"Read the current asynchronous request state, exact payment intent, result, or receipt reference. This is free and never retries or charges a payment."Input schema / properties / job_id / descriptionAdded value: +"Job identifier returned by create_paid_job; polling never retries or charges payment."privatepay_challenge6 fields changedInput schema / descriptionPrevious value: -"Create a structured PrivatePAY x402 V2 payment challenge for an eligible commercial workflow."New value: +"Create a fresh PrivatePAY x402 v2 challenge after checking rail status. This returns payment requirements and the PDAO private-settlement rule; it does not sign, broadcast, or move funds."Input schema / properties / amount_base_units / descriptionAdded value: +"Quoted USDC amount in token base units, not a decimal display amount."Input schema / properties / mime_type / descriptionAdded value: +"Optional response media type for the purchased resource."Input schema / properties / nonce / descriptionAdded value: +"Optional caller nonce used to bind a fresh challenge."Input schema / properties / provider_id / descriptionAdded value: +"PrivatePAY provider or merchant identifier."Input schema / properties / resource / descriptionAdded value: +"Stable HTTPS resource or service identifier being purchased."privatepay_checkout9 fields changedInput schema / descriptionPrevious value: -"Create an official MagicBlock private checkout or request its x402 challenge. No wallet signing or broadcasting occurs."New value: +"Create a MagicBlock PrivatePAY checkout or request its x402 payment-required challenge. This is a quote and preparation step: it never signs, broadcasts, or moves funds."Input schema / properties / amount_base_units / descriptionAdded value: +"Quoted USDC amount in base units."Input schema / properties / description / descriptionAdded value: +"Human-readable commercial description shown in the checkout response."Input schema / properties / expires_in_seconds / descriptionAdded value: +"Challenge lifetime in seconds, between one minute and one day."Input schema / properties / external_reference / descriptionAdded value: +"Merchant-owned idempotency or order reference."Input schema / properties / payer / descriptionAdded value: +"Solana payer wallet public key; never a private key."Input schema / properties / payment_id / descriptionAdded value: +"Existing 64-character checkout identifier when phase is challenge."Input schema / properties / phase / descriptionAdded value: +"Use create for a new checkout or challenge to request the payment-required response for an existing payment_id."Input schema / properties / resource / descriptionAdded value: +"HTTPS resource or service endpoint being purchased."privatepay_job_payment1 field changedInput schema / properties / job_id / descriptionAdded value: +"Job identifier returned by create_paid_job."privatepay_prepare8 fields changedInput schema / descriptionPrevious value: -"Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for local wallet signing. This does not sign or broadcast."New value: +"Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for local wallet inspection and signing. PrivateDAO never receives a private key and this tool never broadcasts."Input schema / properties / amount_base_units / descriptionAdded value: +"Token amount in base units."Input schema / properties / gasless / descriptionAdded value: +"Request the configured sponsored route when supported; the wallet still signs the returned transaction."Input schema / properties / owner / descriptionAdded value: +"Optional destination or balance owner public key."Input schema / properties / payer / descriptionAdded value: +"Wallet public key that will inspect and authorize the transaction."Input schema / properties / phase / descriptionAdded value: +"Unsigned wallet operation to prepare after the challenge: deposit into the private rail, private transfer, or withdrawal."Input schema / properties / request_id / descriptionAdded value: +"PrivatePAY request identifier returned by the challenge or checkout."Input schema / properties / split / descriptionAdded value: +"Optional private transfer split count, from one to fifteen."privatepay_settle4 fields changedInput schema / descriptionPrevious value: -"Request x402 v2 PrivatePAY settlement through the configured payment workflow and return structured settlement evidence."New value: +"Settle an already authorized x402 v2 PrivatePAY payload through the configured facilitator and return redacted settlement evidence. Call privatepay_verify first; this is the only payment-moving PrivatePAY tool and may create a facilitator or on-chain settlement."Input schema / properties / paymentPayload / descriptionAdded value: +"The same finalized payer payload that passed privatepay_verify."Input schema / properties / paymentRequirements / descriptionAdded value: +"The unchanged requirements from the original PrivatePAY challenge."Input schema / properties / x402Version / descriptionAdded value: +"Must be x402 protocol version 2."privatepay_status1 field changedInput schema / descriptionPrevious value: -"Return the fail-closed readiness and privacy boundaries for PrivatePAY x402."New value: +"Read the current PrivatePAY x402 readiness, MagicBlock private-rail configuration, facilitator state, PDAO entry requirement, and public-chain privacy boundary. Use this first; it never creates a challenge or payment."privatepay_verify4 fields changedInput schema / descriptionPrevious value: -"Validate an x402 v2 PrivatePAY payload against the agreed commercial requirements and return structured payment evidence."New value: +"Verify an x402 v2 PrivatePAY payload against the exact challenge requirements through the configured facilitator. This is read-only, fail-closed, and returns redacted structured evidence; call it before privatepay_settle."Input schema / properties / paymentPayload / descriptionAdded value: +"The payer wallet's finalized x402 payment payload, including the accepted scheme and transaction proof."Input schema / properties / paymentRequirements / descriptionAdded value: +"The exact requirements returned by privatepay_challenge or privatepay_checkout; do not substitute a guessed amount or recipient."Input schema / properties / x402Version / descriptionAdded value: +"Must be x402 protocol version 2."cancel_job1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Cancellation result for an unpaid pending request.",
+ "properties": {
+ "cancelled_at": {
+ "description": "Cancellation timestamp when recorded.",
+ "format": "date-time",
+ "type": "string"
+ },
+ "job_id": {
+ "description": "Cancelled request identifier.",
+ "type": "string"
+ },
+ "status": {
+ "description": "Updated cancellation state.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}create_paid_job1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Quote-first service request result; creating the request does not spend funds.",
+ "properties": {
+ "job_id": {
+ "description": "Stable request identifier.",
+ "type": "string"
+ },
+ "payment_intent": {
+ "additionalProperties": true,
+ "description": "Exact quote and recipient details when payment is required.",
+ "type": "object"
+ },
+ "receipt": {
+ "additionalProperties": true,
+ "description": "Public receipt metadata when the request completes.",
+ "type": "object"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Service result when the request completes immediately.",
+ "type": "object"
+ },
+ "status": {
+ "description": "Request status, commonly awaiting_payment or completed.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}discover_agents3 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of ranked agent matches to return."Input schema / properties / network / descriptionPrevious value: -"Optional target network constraint."New value: +"Optional target network constraint used to filter compatible matches."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Ranked discovery result without executing or paying.",
+ "properties": {
+ "agents": {
+ "description": "Registered agent matches.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "capabilities": {
+ "description": "Capability terms used for matching.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "first_party": {
+ "description": "PrivateDAO first-party discovery entry.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "matches": {
+ "description": "Ranked first-party service matches.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "query": {
+ "description": "Natural-language query echoed by the matcher.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}get_provider_integrations1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Provider roles, status signals, and integration disclosures.",
+ "type": "object"
+}get_workflow_guide1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Structured workflow guidance selected by topic.",
+ "properties": {
+ "endpoints": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "description": "Machine endpoints for the selected workflow.",
+ "type": "object"
+ },
+ "free": {
+ "description": "Free-service path when the payment topic is selected.",
+ "type": "string"
+ },
+ "lifecycle": {
+ "description": "Ordered lifecycle stages.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "description": "Exchange or workflow name.",
+ "type": "string"
+ },
+ "paid": {
+ "description": "Ordered paid-service steps when the payment topic is selected.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "payment": {
+ "additionalProperties": true,
+ "description": "Payment rules for the selected workflow.",
+ "type": "object"
+ },
+ "rules": {
+ "description": "Safety rules for the selected workflow.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "states": {
+ "description": "Possible request states.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}job_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Current read-only request state and available evidence.",
+ "properties": {
+ "job_id": {
+ "description": "Stable request identifier.",
+ "type": "string"
+ },
+ "payment_intent": {
+ "additionalProperties": true,
+ "description": "Exact quote when payment is pending.",
+ "type": "object"
+ },
+ "receipt_id": {
+ "description": "Receipt identifier when available.",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Service result when complete.",
+ "type": "object"
+ },
+ "status": {
+ "description": "Current request state.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}list_catalog2 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of entries returned in each selected catalog slice."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Filtered, read-only catalog response.",
+ "properties": {
+ "external": {
+ "description": "Published external capability metadata.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "filter": {
+ "description": "Catalog slice used for the response.",
+ "type": "string"
+ },
+ "network": {
+ "additionalProperties": true,
+ "description": "Supported network capability metadata.",
+ "type": "object"
+ },
+ "products": {
+ "description": "Productized workflow metadata.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "services": {
+ "description": "First-party and published service metadata.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}privatepay_challenge1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Structured PrivatePAY x402 challenge and payment requirements.",
+ "type": "object"
+}privatepay_checkout1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Private checkout terms, request identifiers, and payment requirements.",
+ "type": "object"
+}privatepay_job_payment1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Private payment application result for a selected job.",
+ "type": "object"
+}privatepay_prepare1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Unsigned PrivatePAY preparation context for local wallet authorization.",
+ "type": "object"
+}privatepay_settle1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Structured PrivatePAY settlement evidence.",
+ "type": "object"
+}privatepay_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Fail-closed PrivatePAY readiness and privacy status.",
+ "type": "object"
+}privatepay_verify1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Structured validation evidence for an x402 payment payload.",
+ "type": "object"
+}submit_payment1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Payment confirmation or exact next-step response.",
+ "properties": {
+ "receipt": {
+ "additionalProperties": true,
+ "description": "Public receipt metadata after successful execution.",
+ "type": "object"
+ },
+ "required": {
+ "description": "Required fields when the HTTP payment endpoint must be used.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "status": {
+ "description": "Payment endpoint status or next action.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}verify_receipt4 fields changedInput schema / properties / expected_digest / descriptionAdded value: +"Optional digest that must match the canonical verified record."Input schema / properties / expected_hash / descriptionAdded value: +"Optional result hash that must match the receipt evidence."Input schema / properties / network / descriptionAdded value: +"Optional network identifier for the asset or receipt evidence."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Read-only verification evidence or a public receipt.",
+ "properties": {
+ "evidence_hash": {
+ "description": "Canonical evidence hash when available.",
+ "type": "string"
+ },
+ "receipt": {
+ "additionalProperties": true,
+ "description": "Public receipt metadata when retrieved.",
+ "type": "object"
+ },
+ "receipt_id": {
+ "description": "Public receipt identifier when available.",
+ "type": "string"
+ },
+ "result_hash": {
+ "description": "Verified result hash when available.",
+ "type": "string"
+ },
+ "status": {
+ "description": "Operation status.",
+ "type": "string"
+ },
+ "verification_status": {
+ "description": "Verification result when evidence is accepted.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}privatepay_challenge1 field changedInput schema / descriptionPrevious value: -"Request a PrivatePAY x402 V2 PaymentRequired object. This is unavailable until a reviewed confidential privacy rail is configured."New value: +"Create a structured PrivatePAY x402 V2 payment challenge for an eligible commercial workflow."privatepay_settle1 field changedInput schema / descriptionPrevious value: -"Request x402 v2 PrivatePAY settlement through the reviewed facilitator. This may move funds only after explicit production activation."New value: +"Request x402 v2 PrivatePAY settlement through the configured payment workflow and return structured settlement evidence."privatepay_verify1 field changedInput schema / descriptionPrevious value: -"Forward an x402 v2 PrivatePAY payload to the reviewed facilitator. This fails closed until conformance is verified."New value: +"Validate an x402 v2 PrivatePAY payload against the agreed commercial requirements and return structured payment evidence."agent_matchcancel_jobdiscover_agentsexchange_overviewexecution_guideexternal_servicesget_provider_integrationsget_receiptget_workflow_guidelist_cataloglogistics_requestnetwork_statspayment_guidepdao_servicesproduct_catalogprovider_integrationsreceipt_verifyregister_agentsearch_agentsseller_replace_endpointseller_retireseller_update_servicesservice_recommendationverify_basicverify_receiptcreate_paid_job1 field changedInput schema / properties / payment_modeAdded value: +{
+ "default": "direct",
+ "description": "Select privatepay only when the PrivatePAY x402 status is enabled.",
+ "enum": [
+ "direct",
+ "privatepay"
+ ],
+ "type": "string"
+}privatepay_checkoutprivatepay_job_paymentprivatepay_prepare4 fields changedInput schema / descriptionPrevious value: -"Prepare a real MagicBlock private transfer transaction for the buyer to inspect and sign. This does not sign or broadcast."New value: +"Prepare an unsigned MagicBlock deposit, private transfer, or withdrawal for local wallet signing. This does not sign or broadcast."Input schema / properties / ownerAdded value: +{
+ "pattern": "^[1-9A-HJ-NP-Za-km-z]{32,44}$",
+ "type": "string"
+}Input schema / properties / phaseAdded value: +{
+ "default": "transfer",
+ "enum": [
+ "deposit",
+ "transfer",
+ "withdraw"
+ ],
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "request_id",
- "payer",
- "amount_base_units"
-]New value: +[
+ "request_id",
+ "amount_base_units"
+]privatepay_prepareprivatepay_settleprivatepay_verifyprivatepay_challengeprivatepay_statusexchange_overview1 field changedInput schema / descriptionPrevious value: -"Explain what the PrivateDAO Agent Exchange is, its lifecycle, endpoints, payment rail and verification model."New value: +"Explain the PrivateDAO Agent Exchange, its lifecycle, PDAO utility and holder access, quote-first USDC payment rail, endpoints and verification model."payment_guide1 field changedInput schema / descriptionPrevious value: -"Return the exact quote-first paid-service lifecycle and safety rules."New value: +"Return the exact quote-first lifecycle, PDAO holder-access path and USDC payment safety rules."register_agent8 fields changedInput schema / properties / autoPublishRemoved value: -{
- "description": "Request publication immediately after finalized listing payment if automated screening passes.",
- "type": "boolean"
-}Input schema / properties / auto_publishRemoved value: -{
- "description": "Snake-case compatibility alias for autoPublish.",
- "type": "boolean"
-}Input schema / properties / docsUrlRemoved value: -{
- "description": "Optional public HTTPS documentation URL used for automated screening.",
- "format": "uri",
- "type": "string"
-}Input schema / properties / docs_urlRemoved value: -{
- "description": "Snake-case compatibility alias for docsUrl.",
- "format": "uri",
- "type": "string"
-}Input schema / properties / githubUrlRemoved value: -{
- "description": "Optional public GitHub repository used for automated screening.",
- "format": "uri",
- "type": "string"
-}Input schema / properties / github_urlRemoved value: -{
- "description": "Snake-case compatibility alias for githubUrl.",
- "format": "uri",
- "type": "string"
-}Input schema / properties / websiteUrlRemoved value: -{
- "description": "Optional public HTTPS website used for automated screening.",
- "format": "uri",
- "type": "string"
-}Input schema / properties / website_urlRemoved value: -{
- "description": "Snake-case compatibility alias for websiteUrl.",
- "format": "uri",
- "type": "string"
-}register_agent8 fields changedInput schema / properties / autoPublishAdded value: +{
+ "description": "Request publication immediately after finalized listing payment if automated screening passes.",
+ "type": "boolean"
+}Input schema / properties / auto_publishAdded value: +{
+ "description": "Snake-case compatibility alias for autoPublish.",
+ "type": "boolean"
+}Input schema / properties / docsUrlAdded value: +{
+ "description": "Optional public HTTPS documentation URL used for automated screening.",
+ "format": "uri",
+ "type": "string"
+}Input schema / properties / docs_urlAdded value: +{
+ "description": "Snake-case compatibility alias for docsUrl.",
+ "format": "uri",
+ "type": "string"
+}Input schema / properties / githubUrlAdded value: +{
+ "description": "Optional public GitHub repository used for automated screening.",
+ "format": "uri",
+ "type": "string"
+}Input schema / properties / github_urlAdded value: +{
+ "description": "Snake-case compatibility alias for githubUrl.",
+ "format": "uri",
+ "type": "string"
+}Input schema / properties / websiteUrlAdded value: +{
+ "description": "Optional public HTTPS website used for automated screening.",
+ "format": "uri",
+ "type": "string"
+}Input schema / properties / website_urlAdded value: +{
+ "description": "Snake-case compatibility alias for websiteUrl.",
+ "format": "uri",
+ "type": "string"
+}product_catalogreceipt_verifyMarketplace and payment rail for AI agents: list, buy and settle with signed receipts.
MCP marketplace: AI agents buy services from other agents per call in USDC, plus a bank cash-out
Agent-native MCP for governed commerce, x402 payments, paid capabilities, and verifiable receipts.
Trust and settlement for AI agents: portable attestations, escrow, x402/USDC payments on Solana.
Add one secure layer between your agents and this server.
