Skip to main content
Glama
Sign In

OffshoreProz Agent Company

by io.github.tcgtracker-boop
OverviewDiscussionsAdmin

get_formation_status

Check the live status of a formation request by request_id. Automatically detects incoming USDC payment on-chain (Base, Ethereum, Polygon, Arbitrum, Optimism, Solana); when payment lands it confirms the request, issues Sumsub KYC links for the human members, and returns them. Reports payment status, per-member KYC status, and the filing stage. Poll this after creating a request and after sending payment.

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": {
      "request_id": "<request_id>"
    },
    "name": "get_formation_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
request_idYesThe request_id (UUID) returned by create_formation_request.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it discloses that the call performs on-chain payment detection across six named chains and, on payment landing, confirms the request and issues Sumsub KYC links — a state-changing side effect an agent would otherwise not expect from a 'get' tool. The main gap is polling guidance: no cadence, no rate limits, and no note on whether repeated calls are idempotent.

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?

Three sentences, front-loaded with the core purpose and ending with the actionable polling instruction. The middle sentence is dense with a six-chain parenthetical, but each clause conveys distinct behavior rather than filler.

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

Completeness4/5

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

No output schema exists, and the description compensates by enumerating what is returned: payment status, per-member KYC status, and filing stage. For a polling tool with a state-changing side effect, the only meaningful omission is how frequently to poll and what to do when the request is already confirmed.

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?

Schema coverage is 100% and the single parameter is fully documented in the schema, including its UUID format and provenance from create_formation_request, so the baseline is 4. The description's 'by request_id' adds no meaning beyond that, but nothing is missing either.

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?

States a specific verb and resource ('Check the live status of a formation request') and anchors it to request_id, which cleanly separates it from create_formation_request and the document/calendar siblings. The secondary sentence clarifies that the call also performs payment detection and KYC-link issuance, so an agent knows this is not a pure read.

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

Usage Guidelines4/5

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

'Poll this after creating a request and after sending payment' gives an explicit lifecycle trigger for invocation, which is the key routing signal versus the creation sibling. It stops short of naming alternatives or stating when not to call it (e.g., once filing is complete), so it is clear but not exhaustive.

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

All OffshoreProz Agent Company toolsInspect
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.

Resources