OffshoreProz Agent Company

create_formation_request

Submit a request to form an Agent Company — a Nevis LLC purpose-built to own an autonomous AI agent, contain its liability, and define and prove its authority. Collects the company name, the human principal(s) (owners/members), the agent spec (powers, wallets, spending and risk limits), and whether USD/fiat rails are needed (adds a wholly-owned Wyoming subsidiary). Returns a request_id, the USDC payment address, and next steps. IMPORTANT: this creates a REQUEST for human review only — it NEVER files or moves money automatically. The AI agent is an authorized delegate, NEVER a member or a legal person. Identity documents (passport, DOB, address) are collected only via the secure KYC flow after payment, never through this API.

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": {
      "company_name": "<company_name>",
      "agent": "<agent>",
      "principals": "<principals>"
    },
    "name": "create_formation_request"
  }
}

Input Schema

Name	Required	Description	Default
`agent`	Yes	The autonomous AI agent the company owns and operates. Never a member or a legal person.
`principals`	Yes	Human principal(s) who own the agent and the company. At least one required. The agent is NOT listed here.
`callback_url`	No	OPTIONAL — an HTTPS endpoint the agent controls. We POST signed events there (payment.confirmed, formed) so you never need to poll get_formation_status. The create response returns the signing secret ONCE; verify X-OffshoreProz-Signature (sha256 HMAC of the raw body).
`company_name`	Yes	Desired company name (e.g. "Helios Capital"). "LLC" is appended automatically for the Nevis filing. No "DAO" designator is used — this is an agent company, not a DAO.
`diagnostic_id`	No	If you ran agent_company_diagnostic first, pass the diagnostic_id it returned — links this formation to that assessment.
`needs_usd_rails`	No	Set true if the agent needs USD/fiat (Stripe, US bank). Adds a wholly-owned Wyoming LLC subsidiary for payment rails. Most crypto-native agents can leave this false.
`primary_contact`	No	OPTIONAL human contact. The agent is the primary channel: it gets the payment address and KYC links directly in the tool responses and pays in crypto. Provide a contact only if you want a human emailed a copy.
`management_model`	No	"agent_operated" = the autonomous agent runs day-to-day operations under the Agent Mandate (members retain ultimate control); "member_managed" = humans manage and delegate defined tasks to the agent.	agent_operated
`company_name_alternatives`	No	Backup names in priority order, if the primary is unavailable.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With zero annotations the description carries the full burden and does so: it states that this creates a request for human review only, never files or moves money, returns request_id plus a USDC payment address and next steps, and that identity documents go through a separate secure KYC flow after payment. It also flags the callback signing secret and HMAC verification, which is behavior an agent cannot infer from schema alone.

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?

Front-loaded with the core action and scope, then the return values, then the critical safety caveats. It is a single dense block rather than a structured list, and the 'contain its liability, and define and prove its authority' phrasing is slightly promotional, but no sentence is truly redundant.

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 9-parameter, nested-object tool with no output schema, the description covers what the agent must supply at a high level, what comes back (request_id, payment address, next steps), and the critical what-does-NOT-happen boundary. Nothing essential for a correct first call is left implicit.

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%, so the baseline is 3, but the description adds real meaning beyond it: needs_usd_rails is explained as triggering a wholly-owned Wyoming subsidiary, and the agent/principal separation is reinforced ('the agent is NEVER a member or a legal person', 'the agent is NOT listed here'). It doesn't add much on the numeric spending limits or company_name_alternatives, which are already well documented in the schema.

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 opens with a specific verb and resource ('Submit a request to form an Agent Company') and immediately qualifies it with the exact legal structure (Nevis LLC owning an autonomous AI agent), which distinguishes it from create_standalone_company and agent_company_diagnostic without requiring the agent to open any schema.

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?

Usage context is clear: this is the formation-request entry point, and the schema-and-description note on diagnostic_id tells the agent to run agent_company_diagnostic first and chain the id. What's missing is explicit routing against the closest sibling, create_standalone_company, or any statement of prerequisites/eligibility beyond the KYC note.

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 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.