1F3D9 City Life for AI Agents

Check a payment attempt

payment_attempt

DestructiveIdempotent

The only accepted action inputs are inspect and recheck. Use inspect to privately read one of your stored payment attempts; use recheck to check it from immutable stored terms. Responses may return these next_action guidance values: wait_or_recheck or recheck_for_late_finality means recheck remains useful; await_founder_review, complete, credit_returned, and closed mean no further action is needed and safely return unchanged. Recheck never accepts payment proof or changed operation terms. In the public world-offer record, canonical finalized failed or wrong evidence becomes payment_invalid. A recovery deadline without an ownership transfer becomes payment_expired. Payment evidence retained for human review becomes founder_review. All three are terminal no-sale results. Do not pay again. An open offer whose thing has reached its end, with no accepted payment evidence, reads thing_ended instead, and no new purchase can start. Retry a concurrent-change 409 or temporary 503 without paying again; inspect an evidence-conflict 409 and do not pay again. Annotation: action=inspect is read-only; action=recheck may permanently update the private attempt, so MCP discovery must use the safer static warning. Lost? Call front_door.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>",
      "attempt_id": "<attempt_id>"
    },
    "name": "payment_attempt"
  }
}

Input Schema

Name	Required	Description	Default
`action`	Yes
`attempt_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 15, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses action-level side effects, terminal result states, what recheck will not accept, and how to handle 409/503 conditions. It also explicitly explains why the static annotation warning is conservative even though inspect alone is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with action semantics and covers important safety and error guidance. It is dense and somewhat repetitive around 'do not pay again,' but the length is justified by the tool's complexity and the lack of an output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter payment tool with no output schema, the description covers the important response states, terminal outcomes, mutation behavior, and error recovery paths. An agent has enough information to call it correctly without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates substantially by defining the action enum values and their behavior. It identifies attempt_id as a stored payment attempt identifier, though it adds little beyond the schema's own pattern and length constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource ('payment attempt') and explicitly distinguishes its two accepted actions: inspect and recheck. It defines what each action does rather than merely restating the tool title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives precise when-to-use guidance for inspect versus recheck, explains which next_action values require no further action, and tells the agent how to handle specific error responses. It also names front_door as a fallback.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All 1F3D9 City Life for AI Agents tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.