NAIF Agent Gravity — MCP Diagnostics & Recovery
Server Details
Collision-first MCP diagnostics for MCP, API, webhook and agent failures. Returns structured evidence, bounded repair guidance, agent compatibility checks and safe recovery routing.
- Status
- Healthy
- Uptime
- 99.8% over 23 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- naief9961-tech/ai-growth-engine
- GitHub Stars
- 0
TDQS
Scored across 5 tools
quote_repair, prepare_repair, and request_delegated_purchase overlap in creating quotes/checkouts, requiring careful reading of warnings to distinguish. prepare_repair and request_delegated_purchase both create checkout but from different contexts (existing quote vs autonomous purchase). Descriptions help, but boundaries are not immediately obvious.
All tool names follow a consistent snake_case verb_noun pattern: diagnose_issue, prepare_repair, quote_repair, request_delegated_purchase, verify_repair. No deviations.
Five tools form a focused, well-scoped set covering a diagnostic-to-payment workflow without redundancy. Each tool has a clear place in the flow.
The surface covers diagnosis, quoting, checkout preparation, autonomous purchase, and verification. Minor gaps exist: no tool to query repair job status independently or cancel a quote/checkout, though verify_repair may return job info.
Available Tools
5 toolsdiagnose_issueDiagnose IssueAInspect
Start here. Diagnose one sanitized MCP, API, webhook, agent or integration failure for free. Returns bounded evidence plus a suggested repair service, then use quote_repair only if a priced repair is wanted. It never creates a quote, checkout, payment or repair job. It may record bounded operational attribution/telemetry, so readOnlyHint is false; it does not modify the caller system or commercial state.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Optional attribution label for the calling agent or integration; omit when no stable source label is available. | |
| problem | Yes | One sanitized technical symptom. Include the affected component and observable error/status. Never include secrets, credentials, private keys or PII. |
Output Schema
| Name | Required | Description |
|---|---|---|
| free | No | True for this free diagnostic step. |
| error | No | Present when a bounded diagnosis could not be produced. |
| phase | No | DIAGNOSE on a successful bounded diagnosis. |
| nextTool | No | quote_repair when the caller wants a priced bounded repair. |
| automaticQuote | No | False; diagnosis never creates a quote automatically. |
| rawInputStored | No | False when the raw diagnostic input is not retained as payload data. |
| automaticPayment | No | False; diagnosis never sends or charges payment. |
| automaticCheckout | No | False; diagnosis never creates checkout automatically. |
| automaticExecution | No | False; diagnosis never starts repair execution. |
| suggestedProductId | No | Public repair product suggested from the diagnosis when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reconciles an otherwise confusing annotation by explaining that bounded operational attribution/telemetry is recorded, hence readOnlyHint=false, while asserting it does not modify the caller system or commercial state. It leaves the non-idempotent hint unexplained (repeat calls likely duplicate telemetry) and gives no failure/rate-limit behavior, so it is strong but not exhaustive 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?
Four short sentences, front-loaded with the routing instruction ('Start here'), then deliverable, then sibling routing, then side-effect disclosure. No filler; each sentence 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?
With an output schema present, return values need not be described, and the description still summarizes the response shape. Safety, routing and side effects are covered; the only gap is repeated-call/idempotency behavior for a tool annotated non-idempotent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters including the sanitization and maxLength constraints. The description reinforces 'one sanitized technical symptom' but adds no new syntax or format guidance beyond that baseline.
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 (diagnose) and resource (one sanitized MCP/API/webhook/agent/integration failure), plus the scope limit 'one ... for free' and the concrete deliverable ('bounded evidence plus a suggested repair service'). It explicitly distinguishes itself from quote_repair, so an agent can route 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?
'Start here' establishes it as the entry point, and 'then use quote_repair only if a priced repair is wanted' names the alternative and the exact condition that selects it. Negative guidance is also explicit: it never creates a quote, checkout, payment or repair job, which rules out the downstream siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prepare_repairPrepare RepairAIdempotentInspect
Use ONLY for the normal repair flow after quote_repair has already returned a quoteId and the caller explicitly chooses that existing quote. This tool does not create a quote: with confirm=true it records acceptance of that quote and creates checkout instructions on exactly one rail offered by it. Do NOT use this tool for owner/platform-preauthorized autonomous purchasing where the agent is allowed to choose one of the four capped micro-services and create its own quote; use request_delegated_purchase for that separate flow. APPLE_PAY returns a human handoff URL for buyer authorization; BASE_USDC and TRON_USDT return payer transfer instructions. It never sends funds, charges the caller, verifies payment or directly starts repair execution. After the buyer completes the required payment action, use verify_repair with the returned checkoutId and the same rail.
| Name | Required | Description | Default |
|---|---|---|---|
| rail | Yes | Choose exactly one id from the descriptors in quote_repair.paymentRails. Saudi quotes normally offer APPLE_PAY only. | |
| source | No | Optional attribution label for the calling agent or integration. | |
| confirm | Yes | Must be true to record explicit acceptance before checkout instructions are created. | |
| quoteId | Yes | Exact quoteId returned by quote_repair and explicitly accepted by the caller. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rail | No | Selected payment rail. |
| error | No | Present when quote acceptance or checkout preparation failed. |
| phase | No | PREPARE_REPAIR on success. |
| quoteId | No | Accepted quote identifier. |
| checkout | No | Checkout record/instructions returned for the selected rail; includes the checkout identifier used by verify_repair. |
| nextTool | No | verify_repair after the buyer completes the payment action. |
| fundsSent | No | False; this tool does not send funds. |
| nextAction | No | For APPLE_PAY, human handoff information; for wallet rails, payer transfer instructions. |
| automaticJob | No | False; this preparation step does not start a repair job. |
| paymentVerified | No | False until verify_repair confirms an existing payment. |
| quoteAcceptance | No | Commerce acknowledgement that the quote was accepted. |
| automaticPayment | No | False; no automatic charge or transfer occurs. |
| automaticExecution | No | False; this preparation step does not directly execute repair. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond annotations: APPLE_PAY returns a human handoff URL while BASE_USDC/TRON_USDT return payer transfer instructions. Explicitly states it never sends funds, charges the caller, verifies payment, or starts repair execution. This compensates for idempotentHint scope, which annotations alone do not unpack.
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?
Front-loads the primary condition (ONLY for normal repair flow after quote_repair), then covers exclusions, rail behaviors, non-effects, and the follow-up step in a tight sequence. No filler sentences; every clause carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with an output schema present, the description covers when to use it, what it does and does not do, per-rail outcomes, and the next tool call. Nothing needed to invoke it correctly is missing, and return values are delegated to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents rail, confirm, source, and quoteId. The description reinforces that exactly one enumerated rail id from quote_repair.paymentRails is required and that confirm must be true, but adds no format or syntax beyond the schema. 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 resource: with confirm=true it records acceptance of an existing quote and creates checkout instructions on exactly one rail. It explicitly distinguishes from quote_repair (does not create a quote) and request_delegated_purchase (separate autonomous 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?
Gives explicit when-to-use (after quote_repair returned a quoteId and caller explicitly chose it) and when-not-to-use (owner/platform-preauthorized autonomous purchasing), naming the alternative tool request_delegated_purchase. Also prescribes the next step (verify_repair) and the exact inputs to pass.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_repairQuote RepairAInspect
Use only after diagnose_issue when the caller wants a priced bounded repair. Creates a new non-binding quote for the selected or automatically matched public service. Repeating the call may create a different quoteId, so it is intentionally non-idempotent. It does not accept the quote, create checkout, send payment or start execution. If the quote is accepted by the caller, pass its quoteId and one offered payment rail to prepare_repair.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Optional attribution label for the calling agent or integration. | |
| productId | No | Optional exact public productId suggested by diagnose_issue or chosen from the catalog. Omit to let NAIF match the closest service. | |
| description | Yes | Sanitized bounded repair need derived from diagnose_issue; describe the failure and desired repair outcome without secrets or PII. |
Output Schema
| Name | Required | Description |
|---|---|---|
| eta | No | Estimated delivery time or service ETA when available. |
| error | No | Present when the requested service is unavailable or commerce could not create a quote. |
| phase | No | QUOTE on a successful quote. |
| price | No | Commercial price returned by the quote service. |
| state | No | Current quote state returned by commerce. |
| quoteId | No | Unique non-binding quote identifier to pass to prepare_repair after explicit caller acceptance. |
| currency | No | Quote currency. |
| nextTool | No | prepare_repair after explicit caller acceptance. |
| productId | No | Matched public repair product identifier. |
| exactAmount | No | Exact settlement amount when the selected payment design requires one; preserve it exactly as returned. |
| productName | No | Human-readable matched repair service name. |
| automaticJob | No | False; this tool never starts a repair job. |
| paymentRails | No | Payment rail descriptors offered for this quote; pass one descriptor id to prepare_repair.rail. |
| quoteAccepted | No | False; creating a quote does not accept it. |
| checkoutCreated | No | False; creating a quote does not create checkout. |
| commercialState | No | Commercial lifecycle state when available. |
| automaticPayment | No | False; this tool never sends or charges payment. |
| automaticExecution | No | False; this tool never starts repair execution. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=false and readOnlyHint=false, but the description adds the operational consequence the annotation cannot express: repeating the call may yield a different quoteId. It also enumerates what the tool deliberately does not do, which is real behavioral scope beyond the annotation flags. It stops short of stating auth requirements or quote expiry, so it is strong but not exhaustive.
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?
Four short sentences, front-loaded with the precondition before the mechanics. Every sentence carries a distinct payload: gating, creation semantics, non-idempotency, negative scope, and the successor call. 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?
With an output schema present, return values need not be described, and the description instead supplies the full workflow contract: what precedes it (diagnose_issue), what it produces (quoteId), and what consumes it (prepare_repair). Nothing an agent needs in order 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?
Schema description coverage is 100%, so productId, description and source are already documented with length bounds and semantics; the description's 'selected or automatically matched public service' only echoes the schema's productId omission behavior. No new format or syntax guidance is added, 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 precise verb + resource: 'Creates a new non-binding quote for the selected or automatically matched public service.' It also draws the boundary against siblings by naming diagnose_issue as the prerequisite and prepare_repair as the successor, so an agent can place this tool in the workflow without opening any 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?
Explicit gating condition ('Use only after diagnose_issue when the caller wants a priced bounded repair'), an explicit exclusion list ('does not accept the quote, create checkout, send payment or start execution'), and a named handoff rule ('pass its quoteId and one offered payment rail to prepare_repair'). When-not and alternative routing are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_delegated_purchaseDelegated Purchase (Capped)AInspect
Use ONLY for an owner/platform-preauthorized autonomous purchase of one of four supported micro-services under an explicit spending cap. Unlike prepare_repair, this tool does not consume an existing quoteId: it creates its own quote, accepts it, and creates checkout within the delegation. Repeating the call may create a new quote/checkout, so it is intentionally non-idempotent. Do NOT use it when quote_repair already produced a quoteId or for general repair services outside the four listed micro-services; use prepare_repair for an existing repair quote. Supports wallet rails and APPLE_PAY_AUTO. APPLE_PAY_AUTO requires one human Apple Pay approval first; when Tap returns an ACTIVE saved-card payment agreement, later purchases may be charged only within the stored cap. If provider support or authorization is missing, the flow fails closed.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Optional attribution label for the calling agent or integration. | |
| productId | Yes | Exactly one of the four services allowed for delegated purchase. For any other repair service, use diagnose_issue → quote_repair → prepare_repair. | |
| description | Yes | Sanitized bounded work description for the delegated micro-service; never include secrets, credentials or private keys. | |
| paymentRail | No | Delegated-purchase rail policy. AUTO chooses an eligible wallet rail; APPLE_PAY_AUTO uses or establishes the capped Tap authorization. This is not the manual rail selection for prepare_repair. | |
| maxAmountUsd | Yes | Owner/platform per-purchase spending cap in USD-equivalent. The quote must fit inside this cap and the service launch price. | |
| dailyLimitUsd | No | Requested daily APPLE_PAY_AUTO cap used only during first-time authorization setup; maximum 20 USD. | |
| authorizeCheckout | Yes | Explicit permission for this tool to create its own quote, accept it, and create checkout within the supplied cap. If a quoteId already exists, use prepare_repair instead. | |
| authorizedMerchant | Yes | Merchant scope explicitly authorized by the owner/platform for this delegated purchase flow. | |
| applePayAuthorizationToken | No | Opaque token returned by the one-time APPLE_PAY_AUTO setup. Supply only a token from this delegated authorization flow; never provide card data or raw Apple Pay payloads. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job | No | Repair/delivery job attached by the existing verified-payment workflow when available; may be null. |
| error | No | Fail-closed error code when delegation, price, provider authorization, quote, checkout, or payment requirements are not satisfied. |
| state | No | Provider/checkout state when returned. |
| status | No | Delegated-purchase state such as PAYMENT_REQUIRED, ONE_TIME_APPLE_PAY_AUTHORIZATION_REQUIRED, APPLE_PAY_AUTHORIZATION_NOT_ACTIVE, or a provider payment state. |
| details | No | Bounded provider/commerce error details when available. |
| quoteId | No | Quote created by this delegated call. It was not supplied by the caller. |
| nextTool | No | For wallet rails, verify_checkout_payment after the payer submits the exact transfer. |
| verified | No | When returned by the provider flow, true only for a verified payment. |
| paymentId | No | Verified payment identifier when returned by the provider flow. |
| productId | No | One of the four delegated micro-service product identifiers. |
| checkoutId | No | Checkout created by this delegated call when quote creation/acceptance succeeded. |
| payerAction | No | Required human/payer action before payment can be considered complete. |
| paymentRail | No | Rail actually selected for this delegated purchase. |
| automaticJob | No | False when no verified-payment job has been attached yet. |
| authorization | No | APPLE_PAY_AUTO authorization setup/status information, potentially including the one-time human authorization URL/token. Never interpret this object alone as payment success. |
| automaticQuote | No | True when this tool created the delegated quote itself. |
| automaticPayment | No | False for wallet flows and authorization setup; may only become provider-driven within a previously ACTIVE APPLE_PAY_AUTO agreement. |
| automaticCheckout | No | True when this tool created checkout under the delegation. |
| nextToolArguments | No | Suggested verification arguments for the wallet checkout; txHash remains caller-supplied after payment. |
| automaticExecution | No | False until the existing post-payment workflow has verified payment; this tool does not execute unpaid work. |
| automaticAcceptance | No | True when the delegated quote was automatically accepted under explicit owner/platform authorization. |
| paymentInstructions | No | Wallet transfer instructions for an existing delegated checkout; the tool does not send the transfer. |
| delegatedAuthorization | No | Echo of the enforced merchant/spending delegation, including cap and whether quote acceptance/checkout creation were authorized. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses the non-idempotent quote/accept/checkout lifecycle, the fail-closed behavior when support or authorization is missing, and the APPLE_PAY_AUTO requirement for a one-time human Apple Pay approval plus subsequent stored-cap charging. The idempotentHint=false annotation is reinforced with concrete reasoning rather than merely repeated.
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?
Front-loaded with the primary usage rule, then layers constraints, non-idempotency, and rail semantics in a logical order. Dense but each sentence carries decision-relevant information; slightly long, with minor overlap between the description and the authorizeCheckout/paymentRail schema 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?
Covers authorization prerequisites, spending-cap semantics, the human-approval gate, failure behavior, and sibling routing; an output schema exists so return values need not be described. Nothing an agent needs to call 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?
Schema coverage is 100%, so the schema already documents all nine parameters. The description adds flow-level context (rail policy, token origin, cap enforcement) but little syntax or format detail beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource+scope ('autonomous purchase of one of four supported micro-services under an explicit spending cap') and immediately distinguishes itself from prepare_repair. An agent can tell exactly what this tool does and how it differs from the repair siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('owner/platform-preauthorized', four listed services), when NOT to use ('when quote_repair already produced a quoteId', 'general repair services outside the four listed micro-services'), and names the alternative ('use prepare_repair for an existing repair quote'). Nothing 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.
verify_repairVerify Repair PaymentAIdempotentInspect
Use after the buyer completes the payment action for a checkout created by prepare_repair. APPLE_PAY verifies the existing Tap charge by checkoutId; BASE_USDC and TRON_USDT require the payer-provided txHash. A confirmed payment returns verified=true, while an already-confirmed Apple Pay checkout may return alreadyVerified=true; an unconfirmed or rejected payment returns error and/or reason without fabricating success. Verification may also return the job attached by the existing payment-completion workflow. This tool never creates or sends a transaction and never charges the buyer.
| Name | Required | Description | Default |
|---|---|---|---|
| rail | Yes | Use the same payment rail selected in prepare_repair. | |
| txHash | No | Payer-provided transaction hash. Required for BASE_USDC and TRON_USDT after transfer submission; omit for APPLE_PAY. | |
| checkoutId | Yes | Exact checkout ID returned by prepare_repair. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job | No | Existing repair job attached by the payment-completion workflow when available; may be null. |
| rail | No | Payment rail checked. |
| error | No | Present when payment is missing, unavailable, invalid or could not be verified. |
| phase | No | VERIFY when the verification route returned a structured result. |
| state | No | Payment/checkout state when returned; PAYMENT_VERIFIED denotes a confirmed payment. |
| reason | No | Verification evidence or rejection reason when returned by a wallet rail. |
| verified | No | True only when the provider/chain evidence confirms the expected payment for this checkout. |
| paymentId | No | Recorded verified payment identifier when available. |
| checkoutId | No | Checkout identifier that was verified. |
| alreadyVerified | No | True when an APPLE_PAY checkout had already been verified previously. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond annotations: outcome semantics (verified=true, alreadyVerified=true for repeat Apple Pay checks, error/reason on unconfirmed or rejected payment with no fabricated success), the possibility of a returned job, and an explicit non-mutation guarantee ('never creates or sends a transaction and never charges the buyer'). This is consistent with and enriches idempotentHint=true and destructiveHint=false.
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?
Front-loads the trigger and the non-mutation guarantee, with dense but purposeful sentences and no filler. It is slightly packed into long compound clauses, which costs a bit of scannability.
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?
Covers the three-rail branching, the prerequisite tool, and the success/failure/already-verified outcome space; an output schema exists, so return-shape detail is not required. Essentially everything an agent needs to call this correctly is 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 already documents rail, txHash (including the omit-for-APPLE_PAY rule), and checkoutId. The description's rail-specific restatement confirms intent but adds no syntax or format detail beyond the schema — 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?
States a specific verb (verify) and resource (a repair payment for a checkout), and explicitly anchors it to the sibling prepare_repair as the creating step. An agent can distinguish this from prepare_repair/quote_repair 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 a clear trigger: 'Use after the buyer completes the payment action for a checkout created by prepare_repair,' plus per-rail usage (APPLE_PAY uses checkoutId, BASE_USDC/TRON_USDT need txHash). It does not state when to avoid calling or what to do if prepare_repair was never run, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
prepare_repair1 field changed- changed
Input schema / properties / rail / descriptionPrevious value: -"Choose exactly one rail offered in quote_repair.paymentRails. Saudi quotes normally offer APPLE_PAY only."New value: +"Choose exactly one id from the descriptors in quote_repair.paymentRails. Saudi quotes normally offer APPLE_PAY only."
- Changed
quote_repair5 fields changed- changed
Output schema / properties / paymentRails / descriptionPrevious value: -"Payment rails offered for this quote; choose exactly one of these in prepare_repair."New value: +"Payment rail descriptors offered for this quote; pass one descriptor id to prepare_repair.rail." - added
Output schema / properties / paymentRails / items / additionalPropertiesAdded value: +true - added
Output schema / properties / paymentRails / items / propertiesAdded value: +{ + "id": { + "description": "Rail identifier to pass as prepare_repair.rail.", + "type": "string" + } +} - added
Output schema / properties / paymentRails / items / requiredAdded value: +[ + "id" +] - changed
Output schema / properties / paymentRails / items / typePrevious value: -"string"New value: +"object"
1 tool update
- Changed
request_delegated_purchase32 fields changed- changed
Input schema / properties / applePayAuthorizationToken / descriptionPrevious value: -"Opaque token returned by the APPLE_PAY_AUTO setup. Do not provide card data or Apple Pay payloads."New value: +"Opaque token returned by the one-time APPLE_PAY_AUTO setup. Supply only a token from this delegated authorization flow; never provide card data or raw Apple Pay payloads." - changed
Input schema / properties / authorizeCheckout / descriptionPrevious value: -"Permission to create quote + acceptance + checkout within the stated cap."New value: +"Explicit permission for this tool to create its own quote, accept it, and create checkout within the supplied cap. If a quoteId already exists, use prepare_repair instead." - changed
Input schema / properties / authorizedMerchant / descriptionPrevious value: -"Merchant scope authorized by the owner/platform."New value: +"Merchant scope explicitly authorized by the owner/platform for this delegated purchase flow." - changed
Input schema / properties / dailyLimitUsd / descriptionPrevious value: -"Requested daily APPLE_PAY_AUTO cap during setup; maximum 20 USD."New value: +"Requested daily APPLE_PAY_AUTO cap used only during first-time authorization setup; maximum 20 USD." - changed
Input schema / properties / description / descriptionPrevious value: -"Sanitized bounded work description; never include secrets, credentials or private keys."New value: +"Sanitized bounded work description for the delegated micro-service; never include secrets, credentials or private keys." - changed
Input schema / properties / maxAmountUsd / descriptionPrevious value: -"Per-purchase spending cap in USD-equivalent."New value: +"Owner/platform per-purchase spending cap in USD-equivalent. The quote must fit inside this cap and the service launch price." - changed
Input schema / properties / paymentRail / descriptionPrevious value: -"Choose APPLE_PAY_AUTO for one-time authorization followed by capped automatic purchases."New value: +"Delegated-purchase rail policy. AUTO chooses an eligible wallet rail; APPLE_PAY_AUTO uses or establishes the capped Tap authorization. This is not the manual rail selection for prepare_repair." - changed
Input schema / properties / productId / descriptionPrevious value: -"One of the four delegated-purchase micro-services."New value: +"Exactly one of the four services allowed for delegated purchase. For any other repair service, use diagnose_issue → quote_repair → prepare_repair." - changed
Output schema / descriptionPrevious value: -"For wallet rails returns payment instructions. For APPLE_PAY_AUTO, first use returns a one-time humanAuthorizationUrl plus authorizationToken; subsequent use with an ACTIVE token may return PAYMENT_VERIFIED automatically. Provider activation failures fail closed."New value: +"Result of a capped delegated purchase attempt. For wallet rails, success creates and accepts a quote plus checkout and returns PAYMENT_REQUIRED with payer instructions; payment itself remains external. For APPLE_PAY_AUTO, first use may return ONE_TIME_APPLE_PAY_AUTHORIZATION_REQUIRED with human authorization data, while a later call with an ACTIVE authorization token may return provider payment-verification fields. Treat error or a non-confirmed status as not paid. This schema describes the delegated flow only; normal existing-quote repairs use prepare_repair." - added
Output schema / properties / authorization / descriptionAdded value: +"APPLE_PAY_AUTO authorization setup/status information, potentially including the one-time human authorization URL/token. Never interpret this object alone as payment success." - added
Output schema / properties / automaticAcceptance / descriptionAdded value: +"True when the delegated quote was automatically accepted under explicit owner/platform authorization." - added
Output schema / properties / automaticCheckout / descriptionAdded value: +"True when this tool created checkout under the delegation." - added
Output schema / properties / automaticExecution / descriptionAdded value: +"False until the existing post-payment workflow has verified payment; this tool does not execute unpaid work." - added
Output schema / properties / automaticJobAdded value: +{ + "description": "False when no verified-payment job has been attached yet.", + "type": "boolean" +} - added
Output schema / properties / automaticPayment / descriptionAdded value: +"False for wallet flows and authorization setup; may only become provider-driven within a previously ACTIVE APPLE_PAY_AUTO agreement." - added
Output schema / properties / automaticQuote / descriptionAdded value: +"True when this tool created the delegated quote itself." - added
Output schema / properties / checkoutId / descriptionAdded value: +"Checkout created by this delegated call when quote creation/acceptance succeeded." - added
Output schema / properties / delegatedAuthorization / descriptionAdded value: +"Echo of the enforced merchant/spending delegation, including cap and whether quote acceptance/checkout creation were authorized." - added
Output schema / properties / detailsAdded value: +{ + "description": "Bounded provider/commerce error details when available." +} - added
Output schema / properties / error / descriptionAdded value: +"Fail-closed error code when delegation, price, provider authorization, quote, checkout, or payment requirements are not satisfied." - added
Output schema / properties / jobAdded value: +{ + "description": "Repair/delivery job attached by the existing verified-payment workflow when available; may be null." +} - added
Output schema / properties / nextToolAdded value: +{ + "description": "For wallet rails, verify_checkout_payment after the payer submits the exact transfer.", + "type": "string" +} - added
Output schema / properties / nextToolArgumentsAdded value: +{ + "additionalProperties": true, + "description": "Suggested verification arguments for the wallet checkout; txHash remains caller-supplied after payment.", + "type": "object" +} - added
Output schema / properties / payerActionAdded value: +{ + "description": "Required human/payer action before payment can be considered complete.", + "type": "string" +} - added
Output schema / properties / paymentIdAdded value: +{ + "description": "Verified payment identifier when returned by the provider flow.", + "type": "string" +} - added
Output schema / properties / paymentInstructions / descriptionAdded value: +"Wallet transfer instructions for an existing delegated checkout; the tool does not send the transfer." - added
Output schema / properties / paymentRail / descriptionAdded value: +"Rail actually selected for this delegated purchase." - added
Output schema / properties / productId / descriptionAdded value: +"One of the four delegated micro-service product identifiers." - added
Output schema / properties / quoteId / descriptionAdded value: +"Quote created by this delegated call. It was not supplied by the caller." - added
Output schema / properties / stateAdded value: +{ + "description": "Provider/checkout state when returned.", + "type": "string" +} - added
Output schema / properties / status / descriptionAdded value: +"Delegated-purchase state such as PAYMENT_REQUIRED, ONE_TIME_APPLE_PAY_AUTHORIZATION_REQUIRED, APPLE_PAY_AUTHORIZATION_NOT_ACTIVE, or a provider payment state." - added
Output schema / properties / verifiedAdded value: +{ + "description": "When returned by the provider flow, true only for a verified payment.", + "type": "boolean" +}
1 tool update
- Changed
request_delegated_purchase9 fields changed- added
Input schema / properties / applePayAuthorizationTokenAdded value: +{ + "description": "Opaque token returned by the APPLE_PAY_AUTO setup. Do not provide card data or Apple Pay payloads.", + "maxLength": 240, + "minLength": 20, + "type": "string" +} - changed
Input schema / properties / authorizeCheckout / descriptionPrevious value: -"Explicit permission to create quote + acceptance + checkout within the stated cap; not permission for NAIF to move funds."New value: +"Permission to create quote + acceptance + checkout within the stated cap." - added
Input schema / properties / dailyLimitUsdAdded value: +{ + "description": "Requested daily APPLE_PAY_AUTO cap during setup; maximum 20 USD.", + "exclusiveMinimum": 0, + "maximum": 20, + "type": "number" +} - changed
Input schema / properties / maxAmountUsd / descriptionPrevious value: -"Owner/platform per-purchase spending cap in USD-equivalent."New value: +"Per-purchase spending cap in USD-equivalent." - added
Input schema / properties / paymentRailAdded value: +{ + "description": "Choose APPLE_PAY_AUTO for one-time authorization followed by capped automatic purchases.", + "enum": [ + "AUTO", + "BASE_USDC", + "TRON_USDT", + "APPLE_PAY_AUTO" + ], + "type": "string" +} - changed
Output schema / descriptionPrevious value: -"If eligible, returns PAYMENT_REQUIRED with quoteId, checkoutId and exact wallet payment instructions on BASE_USDC or TRON_USDT. No funds are moved by NAIF."New value: +"For wallet rails returns payment instructions. For APPLE_PAY_AUTO, first use returns a one-time humanAuthorizationUrl plus authorizationToken; subsequent use with an ACTIVE token may return PAYMENT_VERIFIED automatically. Provider activation failures fail closed." - added
Output schema / properties / authorizationAdded value: +{ + "additionalProperties": true, + "type": "object" +} - removed
Output schema / properties / nextToolRemoved value: -{ - "type": "string" -} - changed
Output schema / properties / paymentRail / enumPrevious value: -[ - "BASE_USDC", - "TRON_USDT" -]New value: +[ + "BASE_USDC", + "TRON_USDT", + "APPLE_PAY_AUTO" +]
1 tool update
- Changed
request_delegated_purchase2 fields changed- changed
Output schema / descriptionPrevious value: -"If eligible, returns PAYMENT_REQUIRED with quoteId, checkoutId and exact Base USDC payment instructions. No funds are moved by NAIF."New value: +"If eligible, returns PAYMENT_REQUIRED with quoteId, checkoutId and exact wallet payment instructions on BASE_USDC or TRON_USDT. No funds are moved by NAIF." - added
Output schema / properties / paymentRail / enumAdded value: +[ + "BASE_USDC", + "TRON_USDT" +]
5 tool updates
- Changed
diagnose_issue3 fields changed- changed
Input schema / properties / problem / descriptionPrevious value: -"One sanitized technical symptom. Never include secrets, credentials, private keys or PII."New value: +"One sanitized technical symptom. Include the affected component and observable error/status. Never include secrets, credentials, private keys or PII." - changed
Input schema / properties / source / descriptionPrevious value: -"Optional attribution label."New value: +"Optional attribution label for the calling agent or integration; omit when no stable source label is available." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "Bounded diagnosis result. On success phase is DIAGNOSE and nextTool is quote_repair; an error field indicates diagnosis was unavailable.", + "properties": { + "automaticCheckout": { + "description": "False; diagnosis never creates checkout automatically.", + "type": "boolean" + }, + "automaticExecution": { + "description": "False; diagnosis never starts repair execution.", + "type": "boolean" + }, + "automaticPayment": { + "description": "False; diagnosis never sends or charges payment.", + "type": "boolean" + }, + "automaticQuote": { + "description": "False; diagnosis never creates a quote automatically.", + "type": "boolean" + }, + "error": { + "description": "Present when a bounded diagnosis could not be produced.", + "type": "string" + }, + "free": { + "description": "True for this free diagnostic step.", + "type": "boolean" + }, + "nextTool": { + "description": "quote_repair when the caller wants a priced bounded repair.", + "type": "string" + }, + "phase": { + "description": "DIAGNOSE on a successful bounded diagnosis.", + "type": "string" + }, + "rawInputStored": { + "description": "False when the raw diagnostic input is not retained as payload data.", + "type": "boolean" + }, + "suggestedProductId": { + "description": "Public repair product suggested from the diagnosis when available.", + "type": "string" + } + }, + "type": "object" +}
- Changed
prepare_repair5 fields changed- added
Input schema / properties / confirm / descriptionAdded value: +"Must be true to record explicit acceptance before checkout instructions are created." - added
Input schema / properties / quoteId / descriptionAdded value: +"Exact quoteId returned by quote_repair and explicitly accepted by the caller." - changed
Input schema / properties / rail / descriptionPrevious value: -"Choose exactly one rail offered by quote_repair."New value: +"Choose exactly one rail offered in quote_repair.paymentRails. Saudi quotes normally offer APPLE_PAY only." - added
Input schema / properties / source / descriptionAdded value: +"Optional attribution label for the calling agent or integration." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "Accepted quote plus checkout instructions. A successful result includes checkout information and nextTool=verify_repair; no funds are sent by this tool.", + "properties": { + "automaticExecution": { + "description": "False; this preparation step does not directly execute repair.", + "type": "boolean" + }, + "automaticJob": { + "description": "False; this preparation step does not start a repair job.", + "type": "boolean" + }, + "automaticPayment": { + "description": "False; no automatic charge or transfer occurs.", + "type": "boolean" + }, + "checkout": { + "additionalProperties": true, + "description": "Checkout record/instructions returned for the selected rail; includes the checkout identifier used by verify_repair.", + "type": "object" + }, + "error": { + "description": "Present when quote acceptance or checkout preparation failed.", + "type": "string" + }, + "fundsSent": { + "description": "False; this tool does not send funds.", + "type": "boolean" + }, + "nextAction": { + "additionalProperties": true, + "description": "For APPLE_PAY, human handoff information; for wallet rails, payer transfer instructions.", + "type": "object" + }, + "nextTool": { + "description": "verify_repair after the buyer completes the payment action.", + "type": "string" + }, + "paymentVerified": { + "description": "False until verify_repair confirms an existing payment.", + "type": "boolean" + }, + "phase": { + "description": "PREPARE_REPAIR on success.", + "type": "string" + }, + "quoteAcceptance": { + "additionalProperties": true, + "description": "Commerce acknowledgement that the quote was accepted.", + "type": "object" + }, + "quoteId": { + "description": "Accepted quote identifier.", + "type": "string" + }, + "rail": { + "description": "Selected payment rail.", + "type": "string" + } + }, + "type": "object" +}
- Changed
quote_repair4 fields changed- added
Input schema / properties / description / descriptionAdded value: +"Sanitized bounded repair need derived from diagnose_issue; describe the failure and desired repair outcome without secrets or PII." - added
Input schema / properties / productId / descriptionAdded value: +"Optional exact public productId suggested by diagnose_issue or chosen from the catalog. Omit to let NAIF match the closest service." - added
Input schema / properties / source / descriptionAdded value: +"Optional attribution label for the calling agent or integration." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "Non-binding repair quote. A successful result includes quoteId, price/currency, offered paymentRails and nextTool=prepare_repair. An error field indicates no quote was created.", + "properties": { + "automaticExecution": { + "description": "False; this tool never starts repair execution.", + "type": "boolean" + }, + "automaticJob": { + "description": "False; this tool never starts a repair job.", + "type": "boolean" + }, + "automaticPayment": { + "description": "False; this tool never sends or charges payment.", + "type": "boolean" + }, + "checkoutCreated": { + "description": "False; creating a quote does not create checkout.", + "type": "boolean" + }, + "commercialState": { + "description": "Commercial lifecycle state when available.", + "type": "string" + }, + "currency": { + "description": "Quote currency.", + "type": "string" + }, + "error": { + "description": "Present when the requested service is unavailable or commerce could not create a quote.", + "type": "string" + }, + "eta": { + "description": "Estimated delivery time or service ETA when available." + }, + "exactAmount": { + "description": "Exact settlement amount when the selected payment design requires one; preserve it exactly as returned." + }, + "nextTool": { + "description": "prepare_repair after explicit caller acceptance.", + "type": "string" + }, + "paymentRails": { + "description": "Payment rails offered for this quote; choose exactly one of these in prepare_repair.", + "items": { + "type": "string" + }, + "type": "array" + }, + "phase": { + "description": "QUOTE on a successful quote.", + "type": "string" + }, + "price": { + "description": "Commercial price returned by the quote service." + }, + "productId": { + "description": "Matched public repair product identifier.", + "type": "string" + }, + "productName": { + "description": "Human-readable matched repair service name.", + "type": "string" + }, + "quoteAccepted": { + "description": "False; creating a quote does not accept it.", + "type": "boolean" + }, + "quoteId": { + "description": "Unique non-binding quote identifier to pass to prepare_repair after explicit caller acceptance.", + "type": "string" + }, + "state": { + "description": "Current quote state returned by commerce.", + "type": "string" + } + }, + "type": "object" +}
- Added
request_delegated_purchase - Changed
verify_repair4 fields changed- added
Input schema / properties / checkoutId / descriptionAdded value: +"Exact checkout ID returned by prepare_repair." - added
Input schema / properties / rail / descriptionAdded value: +"Use the same payment rail selected in prepare_repair." - changed
Input schema / properties / txHash / descriptionPrevious value: -"Required for wallet rails; omit for APPLE_PAY."New value: +"Payer-provided transaction hash. Required for BASE_USDC and TRON_USDT after transfer submission; omit for APPLE_PAY." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "Verification status for an existing checkout payment. Treat verified=true or alreadyVerified=true as confirmed; otherwise inspect error/reason/state and do not assume payment success.", + "properties": { + "alreadyVerified": { + "description": "True when an APPLE_PAY checkout had already been verified previously.", + "type": "boolean" + }, + "checkoutId": { + "description": "Checkout identifier that was verified.", + "type": "string" + }, + "error": { + "description": "Present when payment is missing, unavailable, invalid or could not be verified.", + "type": "string" + }, + "job": { + "description": "Existing repair job attached by the payment-completion workflow when available; may be null." + }, + "paymentId": { + "description": "Recorded verified payment identifier when available.", + "type": "string" + }, + "phase": { + "description": "VERIFY when the verification route returned a structured result.", + "type": "string" + }, + "rail": { + "description": "Payment rail checked.", + "type": "string" + }, + "reason": { + "description": "Verification evidence or rejection reason when returned by a wallet rail.", + "type": "string" + }, + "state": { + "description": "Payment/checkout state when returned; PAYMENT_VERIFIED denotes a confirmed payment.", + "type": "string" + }, + "verified": { + "description": "True only when the provider/chain evidence confirms the expected payment for this checkout.", + "type": "boolean" + } + }, + "type": "object" +}
2 tool updates
- Changed
prepare_repair3 fields changed- added
Input schema / properties / rail / descriptionAdded value: +"Choose exactly one rail offered by quote_repair." - changed
Input schema / properties / rail / enumPrevious value: -[ - "BASE_USDC", - "TRON_USDT" -]New value: +[ + "APPLE_PAY", + "BASE_USDC", + "TRON_USDT" +] - changed
Input schema / requiredPrevious value: -[ - "quoteId", - "confirm" -]New value: +[ + "quoteId", + "confirm", + "rail" +]
- Changed
verify_repair3 fields changed- changed
Input schema / properties / rail / enumPrevious value: -[ - "BASE_USDC", - "TRON_USDT" -]New value: +[ + "APPLE_PAY", + "BASE_USDC", + "TRON_USDT" +] - added
Input schema / properties / txHash / descriptionAdded value: +"Required for wallet rails; omit for APPLE_PAY." - changed
Input schema / requiredPrevious value: -[ - "checkoutId", - "rail", - "txHash" -]New value: +[ + "checkoutId", + "rail" +]
29 tool updates
- Removed
accept_service_quote - Removed
agent_compatibility_check - Removed
api_auth_rescue - Removed
checkpoint_agent_task - Removed
create_handoff_capsule - Removed
delegation_preflight - Added
diagnose_issue - Removed
get_agent_traffic_feed - Removed
get_agent_trust_passport - Removed
get_matching_service - Removed
get_repair_packet - Removed
handoff_agent_task - Removed
json_validity_check - Removed
list_fix_topics - Removed
mcp_health_repair - Removed
naif_sos_collision - Added
prepare_repair - Added
quote_repair - Removed
report_traffic_observation - Removed
request_checkout - Removed
request_service_quote - Removed
resolve_technical_error - Removed
resume_agent_task - Removed
traffic_preflight - Removed
verify_checkout_payment - Removed
verify_handoff_capsule - Added
verify_repair - Removed
verify_trust_token - Removed
webhook_rescue
2 tool updates
- Changed
naif_sos_collision2 fields changed- changed
Input schema / properties / source / descriptionPrevious value: -"Optional short attribution label."New value: +"Optional short machine-readable attribution label for the calling agent or integration; it is stored only as diagnostic attribution." - changed
Input schema / properties / text / descriptionPrevious value: -"One sanitized, non-sensitive failure symptom. Do not include secrets."New value: +"One sanitized failure symptom with the affected protocol/component and observable error or status when known. Never include secrets, credentials, private keys or PII."
- Changed
verify_handoff_capsule1 field changed- added
Input schema / properties / capsule / descriptionAdded value: +"Existing signed NAIF continuity capsule token returned by create_handoff_capsule, checkpoint_agent_task or handoff_agent_task; pass the complete token unchanged."
20 tool updates
- Changed
accept_service_quote2 fields changed- added
Input schema / properties / quoteId / descriptionAdded value: +"Quote ID returned by request_service_quote that the caller explicitly chooses to accept." - added
Input schema / properties / source / descriptionAdded value: +"Optional short attribution label for the calling agent or integration."
- Changed
agent_compatibility_check1 field changed- changed
Input schema / properties / text / descriptionPrevious value: -"Sanitized, non-sensitive technical symptoms only."New value: +"Sanitized, non-sensitive symptom text. Include the observable failure and status/error class when known; never include secrets, credentials or private keys."
- Changed
api_auth_rescue1 field changed- changed
Input schema / properties / text / descriptionPrevious value: -"Sanitized, non-sensitive technical symptoms only."New value: +"Sanitized, non-sensitive symptom text. Include the observable failure and status/error class when known; never include secrets, credentials or private keys."
- Changed
checkpoint_agent_task8 fields changed- added
Input schema / properties / capsule / descriptionAdded value: +"Existing signed NAIF continuity capsule to checkpoint or hand off." - added
Input schema / properties / completedAdd / descriptionAdded value: +"New completed steps to append to the capsule state." - added
Input schema / properties / constraintsAdd / descriptionAdded value: +"New constraints to append while preserving earlier constraints." - added
Input schema / properties / nextAction / descriptionAdded value: +"Recommended next bounded action for the receiving agent." - added
Input schema / properties / remainingAdd / descriptionAdded value: +"New remaining steps to append." - added
Input schema / properties / remainingDoneIndices / descriptionAdded value: +"Zero-based indices of prior remaining items now completed." - added
Input schema / properties / requiredCapabilitiesAdd / descriptionAdded value: +"Additional machine-readable recipient capability labels." - added
Input schema / properties / verifiedFactsAdd / descriptionAdded value: +"New sanitized verified facts to append."
- Changed
create_handoff_capsule7 fields changed- added
Input schema / properties / completed / descriptionAdded value: +"Up to 20 concise completed steps already achieved." - added
Input schema / properties / constraints / descriptionAdded value: +"Up to 20 operational constraints the next agent must preserve." - added
Input schema / properties / goal / descriptionAdded value: +"Sanitized task goal that another agent can understand without private context." - added
Input schema / properties / nextAction / descriptionAdded value: +"Recommended next bounded action for the receiving agent." - added
Input schema / properties / remaining / descriptionAdded value: +"Up to 20 remaining steps the next agent may continue." - added
Input schema / properties / requiredCapabilities / descriptionAdded value: +"Machine-readable capability labels required from a recipient agent." - added
Input schema / properties / verifiedFacts / descriptionAdded value: +"Up to 20 sanitized facts already verified and safe to hand off."
- Changed
delegation_preflight1 field changed- added
Input schema / properties / passport / descriptionAdded value: +"Existing signed NAIF Trust Passport token for the opted-in recipient agent."
- Changed
get_agent_trust_passport1 field changed- added
Input schema / properties / agentCardUrl / descriptionAdded value: +"Public agent-card URL for the opted-in agent domain. The domain must publish /.well-known/naif-trust.json."
- Changed
get_matching_service2 fields changed- added
Input schema / properties / description / descriptionAdded value: +"Sanitized problem summary used only to select the closest public NAIF service; include the failure domain and observable symptom." - added
Input schema / properties / source / descriptionAdded value: +"Optional short attribution label for the calling agent or integration."
- Changed
get_repair_packet1 field changed- added
Input schema / properties / slug / descriptionAdded value: +"Exact FixGraph topic slug returned by list_fix_topics or a prior diagnostic response; do not pass free-form error text."
- Changed
handoff_agent_task2 fields changed- added
Input schema / properties / capsule / descriptionAdded value: +"Existing signed NAIF continuity capsule to checkpoint or hand off." - added
Input schema / properties / recipientAgentCardUrl / descriptionAdded value: +"Optional public agent-card URL for the intended opted-in recipient. Omit for an unbound handoff capsule."
- Changed
mcp_health_repair1 field changed- changed
Input schema / properties / text / descriptionPrevious value: -"Sanitized, non-sensitive technical symptoms only."New value: +"Sanitized, non-sensitive symptom text. Include the observable failure and status/error class when known; never include secrets, credentials or private keys."
- Added
naif_sos_collision - Changed
report_traffic_observation7 fields changed- added
Input schema / properties / chain / descriptionAdded value: +"Optional lowercase chain/network label such as base or tron when the route is chain-specific." - added
Input schema / properties / failureClass / descriptionAdded value: +"Normalized failure class when outcome=failure; omit for successful routes." - added
Input schema / properties / latencyBucket / descriptionAdded value: +"Coarse latency bucket only; do not submit precise timing or raw telemetry." - added
Input schema / properties / outcome / descriptionAdded value: +"Final observed technical outcome of the route attempt." - added
Input schema / properties / region / descriptionAdded value: +"Optional two-letter uppercase country/region code for aggregate routing context." - added
Input schema / properties / routeType / descriptionAdded value: +"Observed route protocol class." - added
Input schema / properties / targetClass / descriptionAdded value: +"Type of technical target reached by the route."
- Changed
request_checkout3 fields changed- added
Input schema / properties / quoteId / descriptionAdded value: +"Existing accepted quote ID. Do not use a product ID or checkout ID here." - added
Input schema / properties / rail / descriptionAdded value: +"Payment rail offered by the accepted quote. Omit to use BASE_USDC when eligible." - added
Input schema / properties / source / descriptionAdded value: +"Optional short attribution label for the calling agent or integration."
- Changed
request_service_quote3 fields changed- added
Input schema / properties / description / descriptionAdded value: +"Sanitized bounded work description for this quote; do not include secrets or credentials." - added
Input schema / properties / productId / descriptionAdded value: +"Exact productId returned by get_matching_service or the public catalog." - added
Input schema / properties / source / descriptionAdded value: +"Optional short attribution label for the calling agent or integration."
- Changed
resume_agent_task1 field changed- added
Input schema / properties / capsule / descriptionAdded value: +"Existing signed NAIF continuity capsule token returned by create_handoff_capsule, checkpoint_agent_task or handoff_agent_task."
- Changed
traffic_preflight5 fields changed- added
Input schema / properties / chain / descriptionAdded value: +"Optional lowercase chain/network label such as base or tron when the route is chain-specific." - added
Input schema / properties / region / descriptionAdded value: +"Optional two-letter uppercase country/region code for aggregate routing context." - added
Input schema / properties / routeType / descriptionAdded value: +"Observed route protocol class." - added
Input schema / properties / targetClass / descriptionAdded value: +"Type of technical target reached by the route." - added
Input schema / properties / windowMinutes / descriptionAdded value: +"Lookback window in minutes, from 1 to 60. Omit to use the service default."
- Changed
verify_checkout_payment3 fields changed- added
Input schema / properties / checkoutId / descriptionAdded value: +"Checkout ID returned by request_checkout for the transaction being verified." - added
Input schema / properties / rail / descriptionAdded value: +"Exact payment rail selected for this checkout." - added
Input schema / properties / txHash / descriptionAdded value: +"Existing transaction hash submitted by the payer; this tool never creates or sends a transaction."
- Changed
verify_trust_token1 field changed- added
Input schema / properties / token / descriptionAdded value: +"Existing signed NAIF Trust Passport or Delegation Preflight token to validate."
- Changed
webhook_rescue1 field changed- changed
Input schema / properties / text / descriptionPrevious value: -"Sanitized, non-sensitive technical symptoms only."New value: +"Sanitized, non-sensitive symptom text. Include the observable failure and status/error class when known; never include secrets, credentials or private keys."
3 tool updates
- Added
accept_service_quote - Changed
request_checkout1 field changed- added
Input schema / properties / railAdded value: +{ + "enum": [ + "BASE_USDC", + "TRON_USDT" + ], + "type": "string" +}
- Added
verify_checkout_payment
1 tool update
- Added
json_validity_check
3 tool updates
- Added
get_matching_service - Added
request_checkout - Added
request_service_quote
4 tool updates
- Removed
accept_agent_offer - Removed
get_agent_market_state - Removed
get_dynamic_agent_offers - Removed
x402_payment_doctor
6 tool updates
- Changed
agent_compatibility_check1 field changed- changed
Input schema / properties / text / descriptionPrevious value: -"Sanitized technical symptoms only. Never include secrets, credentials, private keys or PII."New value: +"Sanitized, non-sensitive technical symptoms only."
- Changed
api_auth_rescue1 field changed- changed
Input schema / properties / text / descriptionPrevious value: -"Sanitized technical symptoms only. Never include secrets, credentials, private keys or PII."New value: +"Sanitized, non-sensitive technical symptoms only."
- Changed
mcp_health_repair1 field changed- changed
Input schema / properties / text / descriptionPrevious value: -"Sanitized technical symptoms only. Never include secrets, credentials, private keys or PII."New value: +"Sanitized, non-sensitive technical symptoms only."
- Changed
resolve_technical_error1 field changed- changed
Input schema / properties / text / descriptionPrevious value: -"Technical error text. Never include secrets or private keys."New value: +"Sanitized, non-sensitive technical error text only."
- Changed
webhook_rescue1 field changed- changed
Input schema / properties / text / descriptionPrevious value: -"Sanitized technical symptoms only. Never include secrets, credentials, private keys or PII."New value: +"Sanitized, non-sensitive technical symptoms only."
- Changed
x402_payment_doctor1 field changed- changed
Input schema / properties / text / descriptionPrevious value: -"Sanitized technical symptoms only. Never include secrets, credentials, private keys or PII."New value: +"Sanitized, non-sensitive technical symptoms only."
5 tool updates
- Added
agent_compatibility_check - Added
api_auth_rescue - Added
mcp_health_repair - Added
webhook_rescue - Added
x402_payment_doctor
4 tool updates
- Added
accept_agent_offer - Added
get_agent_market_state - Added
get_dynamic_agent_offers - Changed
resolve_technical_error1 field changed- added
Output schema / properties / agentMarketAdded value: +{}
Related MCP Connectors
Free MCP, API auth, webhook and schema diagnostics with bounded checks and safe quote routing.
Network, domain and website diagnostics for AI clients via MCP.
Remote MCP for A2A failure replay MCP, structured receipts, audit logs, and reviewer-ready evidence.
MCP-native AI SRE: ask what's broken in production, get a reviewed GitHub fix PR.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceAn MCP-native AI incident response system that empowers agents to investigate production incidents, collect evidence, hypothesize root causes, and drive controlled remediation and recovery verification.1-
- AlicenseNot gradedqualityBmaintenanceProvides structured error classification and recovery guidance for MCP agents, turning opaque failures into actionable retry and state information.212 npmMIT
- FlicenseNot gradedqualityBmaintenanceProvides a deterministic failure-decision API for MCP clients, returning one of six actions (RETRY_NOW, WAIT, REPAIR_REQUEST, VERIFY_FIRST, ESCALATE, ABORT) based on failure context to guide safe next steps.-

WSAI FixCenterofficial
AlicenseNot gradedqualityBmaintenanceEvidence-first MCP server for diagnosing problems with hooks, plugins, skills and configuration, returning ranked probable causes and reviewable fixes without modifying the workspace.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.