Track GitHub issue and Stripe test-payment outcomes; recover uncertain supported actions.
Scored across 4 tools
Create and get are clearly distinct. Reconcile and retry both operate on existing operations but represent different actions (consistency vs re-execution), though the terse descriptions leave slight room for confusion.
All tools use the same once_ prefix followed by a verb in snake_case, forming a consistent and predictable pattern throughout.
Four tools is well-scoped for a focused server managing bounded test operations; each tool serves a distinct action without bloat.
The surface covers create, get, reconcile, and retry, but lacks list and delete operations. Without listing, finding existing operations beyond creation is difficult, and no cleanup is possible.
Create one bounded test operation
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| provider | Yes | ||
| parameters | Yes | ||
| idempotency_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and largely fails. It does not disclose that the write is idempotent (despite requiring idempotency_key), which providers/actions are supported, whether it is sandbox-only, or what side effects occur in the target systems.
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 wasted words, but its brevity reflects under-specification rather than tightness. It is appropriately sized but does not use the space it has.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested objects, four required params, two enums, no output schema, and no annotations, one vague sentence is grossly inadequate. An agent would have to inspect the schema and guess at action/provider semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter meaning at all. Four required parameters — including a nested free-form 'parameters' object and an important idempotency_key — are left entirely undocumented in both places.
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 verb+resource ('Create ... operation'), and the create verb differentiates it from siblings once_get/once_reconcile/once_retry. However, 'bounded test operation' is vague jargon — it never says what is actually created (the schema reveals Stripe payment intents and GitHub issues), so an agent cannot confidently predict the effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no mention of the sibling tools for retry/reconcile flows. The only hint ('bounded test') implies a sandbox context but does not state when this should be chosen over once_retry or once_reconcile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get an existing operation
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. "Get" implies a read, but it does not disclose whether the operation must be in a specific state, what happens if the operation_id is invalid, or any return characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, and the core action is front-loaded. It is appropriately concise for a simple getter, though the brevity contributes to the definitional gaps noted elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, and the description does not explain what an operation is, how to obtain its ID, or what the return value contains. For a tool whose parameter is undocumented and whose context is only inferable from siblings, this is inadequate.
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 for the single parameter operation_id is 0%, and the description only implies that it identifies an "existing operation." It does not explain the expected format, origin, or any constraints for the operation_id, leaving the agent to guess.
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 clear verb ("get") and resource ("an existing operation"), so the basic purpose is discernible. However, it does not differentiate this tool from its siblings (once_create, once_reconcile, once_retry) or clarify what kind of "operation" is meant, so an agent still has to infer the context.
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 offers no guidance on when to use this tool versus alternatives. It does not mention once_create, once_reconcile, or once_retry, nor does it state any prerequisites for retrieving an operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reconcile an existing operation
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It does not say whether reconciliation is read-only or mutating, whether it is idempotent, what permissions it needs, or what happens if the operation is already resolved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single phrase contains no filler and is trivially front-loaded, so it is not verbose. However, its brevity comes from under-specification rather than efficient communication, which caps the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter, no annotations, no output schema, and 0% schema coverage, the description is the only source of semantics and it delivers none. An agent cannot tell what the tool returns or what preconditions must hold before calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: operation_id is documented only by name and type. The description does not compensate by explaining what an operation_id is, where to obtain one (presumably from once_create), or what formats are accepted.
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 names a verb ('reconcile') and a resource ('an existing operation'), but 'reconcile' is jargon whose actual effect is never explained. It does not distinguish this tool from once_retry or once_get, leaving the agent to guess whether it re-runs, fixes, or syncs 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?
There is no guidance on when to choose once_reconcile over once_retry or once_get. The only faint signal is 'existing operation', which implies the operation must already exist, but no prerequisite, trigger condition, or exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
retry an existing operation
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says 'retry' but does not disclose side effects, idempotency, required operation state, permissions, rate limits, or 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?
The description is a single front-loaded clause with no wasted words. However, it is so terse that it is arguably under-specified rather than appropriately concise for a tool with no annotations or parameter documentation.
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-like retry tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It does not tell the agent when retrying is valid, what happens during a retry, or how to obtain the required operation_id.
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 for the single required parameter operation_id is 0%, and the description adds no format, source, or meaning beyond the parameter name. It only weakly implies that operation_id identifies an existing operation.
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 ('retry') and resource ('existing operation'), so the core action is clear. It does not distinguish itself from siblings like once_reconcile or once_get, but 'retry' is distinct enough for an agent to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no alternatives, and no prerequisites are given. The phrase implies use when an existing operation needs retrying, but nothing is explicit or contrasted with sibling tools.
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.
once_createonce_getonce_reconcileonce_retryPayment decisions, durable evidence, x402 resource discovery and live gateway status for AI agents.
Cross-session idempotency, URLs as schema-validated JSON, and a record of missing capabilities.
Resolve whether an uncertain side-effecting action completed before software retries it.
Remote HTTPS MCP for Apple + Google Wallet passes. Paste sk_live_ once.
Add one secure layer between your agents and this server.