# io.github.corply-dev/corply (remote · corply.dev)

Incorporate a Delaware C-Corp from your agent — docs, cofounder e-sign, human-reviewed filing.

- Trust score: 70/100 (medium)
- Change this week: +11
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `corply.dev`: 70/100 (this document), [markdown](https://verifymcp.io/servers/corply-dev-corply/corply.md), [page](https://verifymcp.io/servers/corply-dev-corply/corply)

## Channel facts

- Endpoint: `https://corply.dev/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.1.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 91/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
  - The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 53/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (poor).
  - Context-footprint check failed: tool/resource definitions use about 14093 tokens (~234/item across 60 items; 60 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 25/100
  - Stability check failed: schema churn in the 8 days we've observed: 1 tool removals, 0 breaking changes, 0 auth/transport breaks, 4 additions.
- **Tool Coverage**: 78/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 35% of tool parameters carry a description.
- **Capabilities**: 20/100
  - Spec-recency check failed: implements MCP spec 2024-11-05; the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http corply-dev-corply https://corply.dev/mcp
```

### Codex

```toml
[mcp_servers.corply-dev-corply]
url = "https://corply.dev/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "corply-dev-corply": {
      "type": "remote",
      "url": "https://corply.dev/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add corply-dev-corply --url https://corply.dev/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  corply-dev-corply:
    url: "https://corply.dev/mcp"
```

### Other

```json
{
  "mcpServers": {
    "corply-dev-corply": {
      "type": "http",
      "url": "https://corply.dev/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 70, +1)

No change was recorded against any check on this day. Stability & Change Management went from 22 to 25.

### 2026-08-02 (score 69, 0)

- [security] Tool “request_payment” rewrote its description, which is the text the model reads

### 2026-08-01 (score 69, +1)

No change was recorded against any check on this day. Stability & Change Management went from 15 to 18.

### 2026-07-31 (score 68, +7)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 61, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-28 (score 61, +2)

No change was recorded against any check on this day. Schema Quality & AI Usability went from 50 to 53. Other categories moved too: Stability & Change Management rose 3.

### 2026-07-27 (score 59, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 59)

First indexed and scored.

## MCP tools (60)

### `get_company_briefing` (~222 tokens)

FIRST TOOL for company-specific work. Returns the privacy-filtered caller/org/company context, lifecycle origin, formation/payment/filing/document/signature state, standard Delaware C-corp configuration, deterministic operating plan, and execution boundaries. Prerequisite: an authenticated active organization member. No confirmation is required; resolving may materialize the same deterministic canonical plan but creates no external side effect. When multiple companies exist, pass companyId and never guess. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string)
- `itemLimit` (integer)
- `questionLimit` (integer)

### `adopt_existing_company` (~303 tokens)

Attach an already-existing company without creating a Corply formation. Records name, jurisdiction, entity type, date, and file number as founder assertions—not verified facts—then returns a refreshed get_company_briefing result and requests the charter, bylaws, and cap table/stock ledger when available. Prerequisites: active company-manager access, an explicit companyId when the organization has multiple companies, and a stable idempotencyKey. Safe retries with the same key and exact request return the original result; reusing the key for different inputs is rejected. No extra confirmation is required because this records the user's explicit assertion and does not file, pay, sign, invite, or verify anything. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `assertedName` (string, required)
- `companyId` (string)
- `entityType` (string, required)
- `fileNumber` (string)
- `formationDate` (string)
- `idempotencyKey` (string, required)
- `jurisdiction` (string, required)

### `whoami` (~117 tokens)

Return the resolved caller identity (user + org). If pendingInvites is non-empty, tell the user and OFFER to join (confirm before redeem_invite). Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

### `get_org` (~107 tokens)

Compatibility read returning the caller's organization and company identities. Prefer get_company_briefing for company-specific work. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

### `get_status` (~160 tokens)

Return the formation status for a company (or its latest formation): founder-facing checklist, the payment block, THIS caller's pendingSignatures + who else is awaitingOthers, postIncorp tasks, webDashboardUrl, and nextStep — trust nextStep over your own inference of what comes next. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string)
- `formationId` (string)

### `prepare_83b_tin_input` (~225 tokens)

Create a short-lived, one-time external-browser link for the taxpayer to enter the SSN/ITIN required on their exact signed 83(b) election. Use only after that founder has signed. Never ask for, accept, repeat, or place a TIN in chat. The link is reversible and may be refreshed without additional confirmation. Corply never stores the TIN as a database field; Corply Ops receives only a short-lived encrypted mail-ready PDF to print and mail. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `formationId` (string, required)
- `founderId` (string)

### `get_cap_table` (~132 tokens)

Return the company's live cap table: every holder with their security type, shares, price paid, and computed ownership %, plus total shares issued. Auto-seeded with founder common stock at formation. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string)

### `import_cap_table` (~185 tokens)

Import a cap table from a Carta/Pulley CSV export (one-way — Corply becomes the system of record). Owner/founder only. Call with confirm:false first to PREVIEW the parsed holders; confirming REPLACES the company's entire existing cap table with the imported set. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `companyId` (string)
- `confirm` (boolean)
- `csv` (string, required)
- `idempotencyKey` (string): Stable retry key for the confirmed replace-all import.
- `source` (string)

### `save_application` (~222 tokens)

Deep-merge upsert of the structured formation application for a company: incremental saves merge over what's already stored — a partial payload never wipes untouched sections. This reversible intake save needs no confirmation. It refuses changes to a frozen legal packet; use amend_frozen_application after explicit founder confirmation when documents and signatures must be superseded. Returns { formationId, nextStep }. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId`: corply_companies.id (from get_org). OMIT it — the server auto-attaches the org's company. NEVER pass a formationId here.
- `data` (object, required)

### `amend_frozen_application` (~170 tokens)

Apply confirmed answer changes to a frozen, pre-submission formation. This supersedes the frozen legal documents and open signature requests, reopens intake, and requires document regeneration and fresh signatures. Use only after the founder explicitly confirms that consequence. Partial data still deep-merges over stored answers. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `companyId`: corply_companies.id (from get_org). Omit it when the org has one company.
- `data` (object, required)

### `validate_application` (~144 tokens)

Validate the formation application and return missing fields as dotted paths. Promotes the formation to 'ready' when complete and returns the canonical next step. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `formationId` (string, required)

### `check_company_names` (~218 tokens)

Check the formation's saved company name and up to five supplied alternatives through OpenSOSData. Pass the currently saved selectedName exactly and preserve the desired alternative order. Returns every name with available=true, false, or null when only that provider request failed. Previously rejected names return false without another provider call. Results are advisory and never block document generation; Corply operations performs the mandatory Delaware check immediately before filing. No confirmation is required. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `formationId` (string, required)
- `selectedName` (string, required)
- `similarNames` (array, required)

### `generate_documents` (~285 tokens)

Phase-aware immutable generation. Company-name search results are advisory and do not gate this action. Before filing, status 'ready' produces only the filing-stage Certificate of Incorporation. After Delaware acceptance, status 'formed' produces Bylaws, Action of Incorporator, Initial Board Consent, one RSPA per founder, and the unsigned SS-4 using the recorded accepted date. After an electing founder's RSPA is fully executed, Corply automatically produces that founder's 83(b) Election from the actual stock-purchase date and executes it under the advance authorization captured in the founder's signing bundle. A canonical next step may call this tool without another founder confirmation solely to retry that automatic 83(b) preparation. Otherwise, confirm before creating immutable legal documents. Before filing, editing a generated application reopens the formation, supersedes its Certificate and collected signatures, and requires re-generation and re-signing. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: follow the canonical nextStep—confirm when checkpoint=true; an automatic 83(b) preparation retry explicitly needs no new approval.

Input parameters:

- `formationId` (string, required)

### `request_payment` (~218 tokens)

MANDATORY before any signing: prepare (or reuse) the checkout link for the one-time Corply incorporation fee ($799; promo codes accepted at checkout). Show the returned checkoutUrl to the founder in chat as a markdown link — creating the link needs no confirmation; the founder chooses whether to Pay in the browser. Only the lead founder pays, once per company; cofounders never pay, and editing/regenerating documents never re-charges. Safe to re-call: it reuses the open session. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `formationId` (string, required)

### `await_payment` (~274 tokens)

Wait for the incorporation payment to land. Returns {status: 'paid'|'pending'|'expired'|'unpaid'}. Call it in a LOOP until it returns 'paid' — do not call request_signature, invite_cofounders, or submit_for_formation before then; they refuse with PAYMENT_REQUIRED. 'expired' → run request_payment again for a fresh link. 'unpaid' → no session yet; run request_payment first. Each call waits at most ~8 seconds by design — long-held requests get killed by the gateway. Call it REPEATEDLY until it returns 'paid'; a 'pending' result includes retryAfterSeconds. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `formationId` (string, required)
- `maxWaitSeconds` (integer): Seconds to wait before returning (ceiling ~10s — the gateway kills longer-held requests).

### `request_signature` (~279 tokens)

Requires the incorporation fee to be PAID first (request_payment → await_payment). Phase-aware and idempotent: before Delaware acceptance it prepares signatures only for the filing-stage Certificate of Incorporation; after acceptance it requests signatures for the generated organizational documents and each founder's Restricted Stock Purchase Agreement. Once an electing founder's RSPA is fully executed and the canonical stock-purchase date exists, Corply automatically generates and executes that founder's Section 83(b) election under the bundle's advance authorization—there is no later signature or confirmation. This preparatory action needs no confirmation and sends no cofounder email. It returns only the caller's safe server-issued signing bundle and review link; present reviewUrl as a markdown link. Use the separately confirmed invite_cofounders or nudge_signer action for external messages. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `formationId` (string, required)

### `sign_bundle` (~254 tokens)

Record one binding ESIGN/UETA consent for the exact server-issued bundle returned by get_status or request_signature. CALLER GATE: only the live signer may call it, after reviewing every listed document and giving one fresh affirmative act. Never reuse prior-session consent or sign for an absent cofounder. The opaque bundleId prevents omitted, added, or stale documents. For an eligible founder who already elected Section 83(b), the post-incorporation bundle also grants advance authorization: once the RSPA establishes the transfer date, Corply automatically completes and executes the election without another signature or confirmation. Then show/open the returned external-browser TIN link immediately and never ask for the TIN in chat. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `bundleId` (string, required)
- `esignConsent` (boolean, required)
- `formationId` (string, required)
- `signedLegalName` (string, required)

### `submit_for_formation` (~140 tokens)

Requires the incorporation fee to be PAID first (request_payment → await_payment). Hand the fully-signed formation to the human filing pipeline, then best-effort notify the organization and email the signed incorporation documents to each founder. Does NOT file with Delaware. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `formationId` (string, required)

### `remember` (~125 tokens)

Persist a durable decision/fact into the organization's context memory. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `text` (string, required)

### `recall` (~113 tokens)

Search the organization's context memory + Corply reference KB for relevant facts. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `includeGlobal` (boolean)
- `query` (string, required)

### `invite_member` (~152 tokens)

Invite a cofounder to this organization by email. Call only after the founder explicitly confirms the invitation. This membership invitation is independent of name checks, documents, payment, and signatures. They join from their own connected Corply session by signing in with that email. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `companyId`
- `email` (string, required)
- `role` (string, required)

### `redeem_invite` (~138 tokens)

Join an organization with an invite join code. Ask the user to confirm first ('Join {company} as a cofounder?') — joining switches your active organization and best-effort emails the other active organization members that their cofounder joined. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `joinCode` (string, required)

### `invite_cofounders` (~171 tokens)

Requires the incorporation fee to be PAID first (request_payment → await_payment). Compatibility action that emails each OTHER listed founder's pending review-and-sign link after documents are generated. It never creates or refreshes membership invitations; use invite_member earlier, after explicit founder confirmation. Only run when the lead explicitly asks. Sign links are delivered directly to each cofounder and are shown here only when their email fails. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `formationId` (string, required)

### `nudge_signer` (~118 tokens)

Re-send the signature reminder email to a cofounder who hasn't signed yet. Only when the lead asks. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `email` (string, required)
- `formationId` (string, required)

### `mark_task_done` (~172 tokens)

Report one of YOUR post-incorporation tasks as done (for example, opening your bank account) with an optional note. Corply's team verifies and completes it — status becomes 'pending review'. Only works for tasks assigned to the founder. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `note` (string)
- `stepKey` (string, required)

### `prepare_revenue_launch` (~327 tokens)

LEGACY PADDLE SUBSCRIPTION MIGRATION ONLY; for a new Corply-controlled payment portal call get_payment_pipeline_status instead. The calling coding agent must inspect framework, package manager, app/source root, and test/build commands itself before calling—never ask the founder for repository metadata. Reuses the authenticated company's non-secret formation facts, classifies whether the older fixed-price SaaS subscription Paddle merchant-of-record path fits, and returns only the commercial facts that genuinely need founder input. Makes zero provider calls and no writes; never requests credentials, identity documents, bank/card data, or acceptance of terms. If multiple companies exist, pass an exact companyId from get_company_briefing. Trust nextTool and do not bypass an unsupported marketplace, digital-goods, one-time/mixed/usage billing, physical-goods, or services result. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `billingModel` (string, required)
- `businessModel` (string, required)
- `companyId` (string)
- `customerType` (string, required)
- `productDescription` (string)
- `productName` (string)
- `repository` (object, required)
- `targetCountries` (array, required)
- `websiteUrl` (string)

### `create_payment_project` (~289 tokens)

Legacy Paddle path only. After prepare_revenue_launch returns sandbox_build_ready, deterministically generate the integrity-hashed sandbox-only manifest that the agent will commit inside an existing legacy integration. This is a pure draft action: it stores no hosted state, makes zero provider calls, creates no Paddle account/catalog, charges nothing, and accepts no secret values. The hash detects drift but is not a provider approval or cryptographic signature. Same company + projectKey + inputs returns the same project and hash. Next call configure_payment_catalog. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `billingModel` (string, required)
- `businessModel` (string, required)
- `companyId` (string)
- `customerType` (string, required)
- `productDescription` (string)
- `productName` (string)
- `projectKey` (string, required): Stable slug generated by the agent from product/repository context; do not ask the founder to invent it.
- `repository` (object, required)
- `targetCountries` (array, required)
- `websiteUrl` (string)

### `configure_payment_catalog` (~228 tokens)

Validate and deterministically add the founder-approved fixed-price SaaS subscription catalog to an integrity-hashed Corply Pay manifest. The agent derives technical product/price/entitlement keys, environment-variable names, and the SaaS category matching the already-approved business model; do not ask the founder for implementation identifiers or a tax code. Inputs contain environment-variable NAMES only—never Paddle IDs, API keys, webhook secrets, bank/card data, or customer data. Makes zero provider calls and charges nothing. Refuses drifted manifests, duplicate identifiers, model/category mismatches, or catalog/billing-model contradictions. Next call create_payment_integration_bundle. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `manifest` (object, required)
- `products` (array, required)

### `create_payment_integration_bundle` (~277 tokens)

Generate a reviewable repository patch plan from a valid catalog manifest: the unpublished local @corply/payments alpha package coordinate, exact manifest, environment-variable-name template, structured external Paddle sandbox setup handoff, framework adapter files, and required verification checks. Makes zero provider/network calls, writes no files itself, never overwrites existing files, and never handles credential values. The manifest is verify-exact and must never be merged field-by-field; generated code is create-only and code collisions require deliberate integration. The calling agent must inspect each target path, apply safe files, follow the provider handoff only after founder authentication, run every returned check locally, capture SHA-256 evidence references, call verify_payment_integration with truthful pass/fail/not-run evidence, repair from its report, and repeat. Do not execute the afterPublishCommand until the package is actually published. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `includeExamplePricingPage` (boolean, required)
- `manifest` (object, required)

### `verify_payment_integration` (~259 tokens)

Inventory caller-reported local/sandbox evidence references against every required Corply Pay control: build/type tests, webhook authenticity/idempotency/out-of-order delivery, subscription lifecycle, deny-by-default entitlements, tenant isolation, return-URL validation, secret scan, and sandbox checkout. This tool reports only whether that caller-supplied inventory is complete; it does not execute or independently attest commands, establish sandbox or production readiness, or make provider calls. Passed/failed results require the exact command and a SHA-256 evidence reference. Evidence inventory completeness NEVER completes KYB/KYC, terms, payout-bank, provider approval, refunds, money movement, migrations, deployment, or production go-live; report those as explicit unverified human/external actions and require fresh founder confirmation for any later live action. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `checks` (array, required)
- `manifest` (object, required)

### `get_payment_pipeline_status` (~193 tokens)

Canonical read for Corply's own payment pipeline: returns non-secret merchant routes, lifecycle counts, gross settled/refunded/paid-out totals, recent payment state, reconciliation state, and exact blockers for one company. It never returns provider credentials, hosted payment tokens, bank/card data, or customer data; makes zero provider calls and moves no money. Use this instead of the legacy Paddle integration planner when the founder wants Corply-controlled payment portals. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string)
- `recentPaymentLimit` (integer, required)

### `create_payment_route_draft` (~252 tokens)

Create or exactly replay one local sandbox merchant-route draft for Corply's own payment pipeline. This reversible backend save accepts only company, route key, USD, and an idempotency key; it cannot accept or store credentials, provider IDs, identity documents, terms acceptance, bank/card data, or a production setting. It makes zero provider calls, creates no external account, activates nothing, and moves no money. Afterward call get_payment_pipeline_status; provider onboarding, payout-bank connection, route activation, and live enablement remain separately confirmed actions. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string)
- `currencies` (array, required)
- `idempotencyKey` (string, required)
- `routeKey` (string, required)

### `start_payment_route_onboarding` (~252 tokens)

Create or recover the secure hosted Moov sandbox onboarding link for one existing Corply payment route. This makes an idempotent provider call after a durable local claim, pre-fills only the canonical legal business name, and asks the founder to complete identity, ownership, underwriting, pricing disclosure, capability, and payout-bank setup directly with Moov. It never receives identity documents, bank/card data, provider credentials, or terms acceptance in chat, activates no route, and moves no money. Return the onboardingLink to the founder, then call get_payment_pipeline_status after they complete it. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string)
- `idempotencyKey` (string, required)
- `routeId` (string, required)

### `refresh_payment_route_onboarding` (~219 tokens)

Read the exact hosted Moov sandbox onboarding invite, required capability statuses, default wallet, and verified payout-bank method for one Corply route, then converge the server-only route connection. It accepts no provider IDs, credentials, identity documents, bank/card data, or terms acceptance from chat. It makes provider reads only, never changes the provider account, and activates the sandbox route only when all required provider facts are currently ready; it moves no money and cannot enable production. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string)
- `routeId` (string, required)

### `reconcile_payment_route` (~208 tokens)

Read the exact active Moov sandbox wallet balance and compare it with Corply's immutable route-scoped platform-cash postings, then record a hash-bound reconciliation run. It makes provider reads only, exposes no provider account, wallet, credential, bank/card, or customer data, and moves no money. The first run may anchor a pre-existing wallet balance only before any payment or journal activity; later variance fails readiness closed. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string)
- `routeId` (string, required)

### `run_sandbox_payment_probe` (~266 tokens)

After fresh founder confirmation of the exact USD 1.00 Moov sandbox charge, create or replay one server-priced diagnostic order and send its server-configured card-payment source through Corply's durable create-and-authorize pipeline. The tool accepts no provider IDs, card/bank data, customer data, amount, currency, merchant, fee, reserve, or payout destination. It requires an active route, a fresh zero-variance reconciliation, server-held probe configuration, and an exact idempotency key. This is test-mode money movement only; it cannot charge live money, enable production, or prove settlement by itself. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string)
- `confirmation` (string, required)
- `idempotencyKey` (string, required)
- `routeId` (string, required)

### `run_sandbox_payout_probe` (~271 tokens)

After fresh founder confirmation of the exact USD 0.01 Moov sandbox payout, send one cent from one exact settled diagnostic payment through Corply's durable payout command to the route's server-resolved verified standard-ACH bank. The tool accepts no amount, currency, provider ID, wallet, bank/card data, or payout destination. It requires the exact paymentKey, active sandbox route, fresh zero-variance reconciliation, and verified bank. This is test-mode money movement only; the scheduled worker records the provider's exact after-the-fact payout fee from transfer and wallet evidence before reconciliation can pass. It cannot move live money or enable production. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string)
- `confirmation` (string, required)
- `paymentKey` (string, required)
- `routeId` (string, required)

### `open_bank_account` (~158 tokens)

Open a Corply Bank account for this company — account and routing numbers are issued instantly. Corply Bank is agent-first: everything (transfers, cards, agent wallets, approvals) runs through these tools. Confirm with the founder before opening. Fund the new account with bank_transfer. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `nickname` (string): Display name, defaults to 'Checking'.
- `type` (string)

### `bank_transfer` (~252 tokens)

Move money by ACH or wire on a Corply Bank account. direction 'in' records an incoming transfer (e.g. an investor wire landing); direction 'out' sends money and requires sufficient balance. State the exact amount, direction, and counterparty to the founder and get fresh confirmation before calling. If a call times out or errors ambiguously, refresh get_bank_overview or list_bank_activity to confirm whether the transfer posted before retrying — never blind-retry. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `accountId` (string): Defaults to the org's open account.
- `amountCents` (integer, required): Transfer amount in integer cents (e.g. $2,000 → 200000).
- `counterparty` (string, required): Who the money comes from or goes to.
- `direction` (string, required)
- `memo` (string)
- `method` (string, required)

### `get_bank_overview` (~138 tokens)

FIRST TOOL for banking work: the live Corply Bank snapshot — accounts and balances, issued cards, agent wallets (budget, spent, remaining, status), pending approvals awaiting the founder, and recent transactions. Present it clearly; never state balances from memory. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

### `issue_card` (~218 tokens)

Issue a Corply card to an active organization member (founder or cofounder), virtual or physical, with optional monthly and per-transaction limits. Virtual cards return full card details in the result. Confirm holder, kind, and limits with the founder before calling. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `cardKind` (string, required)
- `memberEmail` (string, required): Email of the active org member who will hold the card.
- `perTransactionLimitCents` (integer): Per-transaction limit in integer cents (e.g. $2,000 → 200000).
- `spendingLimitCents` (integer): Monthly spending limit in integer cents (e.g. $2,000 → 200000).

### `create_agent_wallet` (~341 tokens)

Create an agent wallet: task-scoped spending authority the founder grants to an AI agent, with a hard budget, optional per-transaction cap, category allowlist, and expiry. A virtual card is issued with it that works anywhere cards are accepted, including Corply Payments portals. The wallet policy is the founder's standing authorization: in-policy spends post without further confirmation, out-of-policy spends wait for respond_to_approval. Confirm the budget and limits with the founder before calling. Category-restricted wallets can spend only via wallet_spend — checkout portals carry no category and will decline them. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `accountId` (string): Defaults to the org's open account.
- `allowedCategories` (array): Restrict spend categories (e.g. ['software','ads']). Omit for unrestricted.
- `budgetCents` (integer, required): Total budget in integer cents (e.g. $2,000 → 200000).
- `expiresAt` (string): ISO timestamp when the wallet expires.
- `name` (string, required): Wallet name, e.g. 'Launch-week ads agent'.
- `perTransactionCapCents` (integer): Per-transaction cap in integer cents (e.g. $2,000 → 200000).
- `taskDescription` (string): What the agent is authorized to accomplish.

### `update_agent_wallet` (~240 tokens)

Change an agent wallet: 'topup' adds budget, 'freeze'/'unfreeze' pause and resume spending, 'close' ends it permanently, 'set_caps' changes the per-transaction cap, categories, or expiry. Confirm the exact change with the founder before calling. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `action` (string, required)
- `allowedCategories`: New category allowlist; null removes the restriction; omit to leave unchanged.
- `expiresAt`: New ISO expiry; null removes the expiry; omit to leave unchanged.
- `perTransactionCapCents`: New per-transaction cap in cents; null removes the cap.
- `topUpCents` (integer): Top-up amount in integer cents (e.g. $2,000 → 200000).
- `walletId` (string, required)

### `wallet_spend` (~275 tokens)

Spend from an agent wallet the founder configured. The wallet's budget, per-transaction cap, categories, and expiry ARE the founder's standing authorization — an in-policy spend posts immediately without another confirmation. If the spend falls outside policy the result is APPROVAL_REQUIRED with an approvalId: surface it to the founder and do not retry; the founder decides with respond_to_approval. If a call times out, check list_bank_activity for the posted spend before retrying — never blind-retry. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `amountCents` (integer, required): Spend amount in integer cents (e.g. $2,000 → 200000).
- `category` (string): Spend category, e.g. 'software'.
- `counterparty` (string, required): Merchant or payee.
- `memo` (string)
- `walletId` (string, required)

### `respond_to_approval` (~159 tokens)

The founder's decision on a wallet spend that exceeded its policy. 'approve' executes the held spend immediately and returns the posted transaction; 'deny' rejects it. Only call after the founder has seen the amount, counterparty, and reason, and explicitly decided in this session. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `approvalId` (string, required)
- `decision` (string, required)
- `note` (string)

### `list_bank_activity` (~152 tokens)

The Corply Bank monitoring feed: transactions and wallet approval events, newest first, filterable by account or wallet. Use it to show the founder exactly what an agent has been spending and what is waiting on them. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `accountId` (string)
- `limit` (integer)
- `walletId` (string)

### `create_payment_portal` (~283 tokens)

Create the company's hosted Corply Payments checkout portal and return its public URL. The portal accepts card payments from people AND purchases from AI agents (machine-readable checkout at the returned agentEndpoint) — share the URL with customers as-is. This is the hosted checkout surface, distinct from the payment-route onboarding tools (create_payment_route_draft etc.). Re-calling with the same slug (or a name that slugifies to it) returns the existing portal unchanged — this tool never edits an existing portal. Show the returned url to the founder as a markdown link. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `accentColor` (string): Hex color like #1A1A1A.
- `description` (string)
- `name` (string, required): Business or product name shown on the portal.
- `slug` (string): URL slug; defaults to a slugified name.
- `tagline` (string)

### `create_payment_link` (~326 tokens)

Create a Corply Payments magic link — a shareable URL that collects one payment (or many, with singleUse false). Omit amountCents to let the payer choose the amount. Works for humans on the hosted page and for agents at the returned agentEndpoint. Show the returned url as a markdown link. Each call creates a NEW live link — it never returns an existing one; after a timeout or ambiguous error, check list_portal_payments for the link before re-creating. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `amountCents` (integer): Fixed amount in integer cents (e.g. $1,200 → 120000); omit to let the payer choose.
- `description` (string)
- `expiresAt` (string): ISO timestamp after which the link stops working.
- `portalId` (string): Portal id from a previous result; defaults to the org's first ACTIVE portal.
- `singleUse` (boolean): Default true: the link closes after one payment.
- `title` (string, required): What is being paid for, e.g. 'Invoice #12 — API integration'.

### `pay_payment_link` (~417 tokens)

Buy something: pay a Corply Payments link with one of this company's agent wallets. Give it the link the seller shared (the /pay/link/ URL, its agentEndpoint, or the bare token) and the walletId — Corply resolves that wallet's own virtual card server-side, so never ask the founder for a card number and never put one in a message. The wallet's budget, per-transaction cap, categories, and expiry ARE the founder's standing authorization: an in-policy purchase completes immediately without another confirmation, and an out-of-policy one comes back status 'declined' with a reason and a plain-language 'why' — report that and stop rather than retrying. Remember the wallet budget is authority, not money: a spend larger than the backing account's balance declines 'insufficient_funds'. Works across companies — paying another org's link settles to that seller. On success returns the receipt number plus the wallet's remaining budget. If a call times out, check list_portal_payments (seller) or list_bank_activity (buyer) before retrying — a repeat call buys again. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `agentIdentity` (string): Who the buyer is on the seller's receipt; defaults to the wallet name.
- `amountCents` (integer): Only for links that let the payer choose; fixed-price links ignore it.
- `link` (string, required): The payment link URL, its agentEndpoint, or the bare link token.
- `walletId` (string, required): Which agent wallet pays. From get_bank_overview.

### `list_portal_payments` (~169 tokens)

Revenue feed for the company's Corply Payments portals: recent charges (newest 100; totals cover that window) (human or agent payer, method, receipt), link statuses, and totals including the share of revenue paid by agents. Read this instead of ever asserting payment activity from memory. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: reads current server state and does not manufacture company facts. Idempotency: safe to repeat. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `portalId` (string): Portal id from a previous result; omit to cover all the org's portals.

### `resolve_company_plan` (~233 tokens)

Deterministically resolve and materialize the company's current operating graph. The lifecycle is always running—never report globally done. Treat unknown facts as unknown and ask only returned questions; never infer immigration/work permission or restricted personal facts. Honor evidence, signature, payment, authority, licensed-professional, and other human boundaries before acting. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string): corply_companies.id. May be omitted only when the active organization has exactly one company.
- `itemLimit` (integer, required): Maximum items returned per actionable/blocked/waiting section.
- `questionLimit` (integer, required): Maximum targeted missing-fact questions returned.

### `upsert_operating_subject` (~355 tokens)

Create or update one durable company-owned subject, including a person, location, product, offering, customer, vendor, contract, equity award, account, or obligation, then freshly resolve the plan. Use a stable externalKey; store decision facts through record_operating_fact, not opaque attributes. Never fabricate personal, immigration, or credential data. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `attributes` (object): Allowlisted integration linkage only. Citizenship, visa, tax, ID, health, credential, compensation, and other decision data must be typed facts.
- `companyId` (string): corply_companies.id. May be omitted only when the active organization has exactly one company.
- `displayName` (string, required)
- `externalKey` (string, required): Stable caller-controlled identity, e.g. founder:<uuid> or product:billing.
- `itemLimit` (integer, required): Maximum items returned per actionable/blocked/waiting section.
- `linkedUserId`: Owner/operator-only account link for subject-self private access. Omit to preserve; null to unlink. The target must be an active org member.
- `questionLimit` (integer, required): Maximum targeted missing-fact questions returned.
- `status` (string, required)
- `subjectType` (string, required)

### `manage_operating_access_grant` (~299 tokens)

Owner/operator-only grant or revocation of one person's expiring access to one restricted operating-data class. Use the narrowest subject and class, explain the business purpose, cap access at 90 days, and revoke immediately when the engagement ends. Revocation is retained as an audit tombstone. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `action` (string, required)
- `companyId` (string): corply_companies.id. May be omitted only when the active organization has exactly one company.
- `dataClass` (string): Required for grant; grant exactly one class at a time.
- `expiresAt` (string): Required for grant; must be in the future and no more than 90 days away.
- `grantId` (string): Required for revoke; the immutable grant record to tombstone.
- `granteeUserId` (string): Required for grant; must be an active member of the organization.
- `reason` (string, required): Specific reviewed purpose for granting or revoking access.
- `subjectId` (string): Optional person/subject scope. Omit only for a genuinely company-wide fact class.

### `record_operating_fact` (~446 tokens)

Record a typed, versioned company or subject fact and freshly resolve the plan. High-impact facts become canonical only with the registry's required confirmation/evidence. Never infer immigration status, work authorization, tax/legal conclusions, or other restricted facts; record explicit evidence or a qualified professional determination. A non-promoted candidate is not safe to treat as true. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string): corply_companies.id. May be omitted only when the active organization has exactly one company.
- `confidence` (number)
- `confirmationKind` (string, required)
- `effectiveFrom` (string)
- `effectiveTo` (string)
- `evidenceEventIds` (array)
- `expiresAt` (string)
- `factKey` (string, required): Registry key without company./subject. prefix, e.g. entity.formed or work.authorization_basis.
- `itemLimit` (integer, required): Maximum items returned per actionable/blocked/waiting section.
- `provenance` (object): Non-secret structured provenance metadata.
- `questionLimit` (integer, required): Maximum targeted missing-fact questions returned.
- `sourceObservedAt` (string)
- `sourceRef` (string, required): Stable provenance reference; do not put a secret or raw document body here.
- `sourceType` (string, required): Provenance class, e.g. user_assertion, document, external_system, operator, or professional.
- `subjectId` (string): Required for subject-scoped facts (people, locations, products, offerings, customers, vendors, contracts, awards, accounts, or obligations); omit for company facts.
- `trustLevel` (integer)
- `value` (required): Typed JSON value matching the inspected fact definition.

### `record_operating_event` (~426 tokens)

Atomically stage or promote one event occurrence's stable ID and mutable anchor fact. Use this for every fact named by an event rule; scalar writes are rejected to prevent mixed IDs/deadlines. If evidence is required, the first call returns candidate fact IDs. Bind evidence to each evidence-gated candidate, then retry with identical source and validity inputs; both facts become canonical in one transaction. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `anchorValue` (required): Typed value for the rule's recurrence.anchorFact.
- `companyId` (string): corply_companies.id. May be omitted only when the active organization has exactly one company.
- `confidence` (number)
- `confirmationKind` (string, required)
- `effectiveFrom` (string)
- `effectiveTo` (string)
- `evidenceEventIds` (array)
- `expiresAt` (string)
- `itemLimit` (integer, required): Maximum items returned per actionable/blocked/waiting section.
- `occurrenceId` (string, required): Stable episode identity, never a mutable date, boolean, or label.
- `provenance` (object)
- `questionLimit` (integer, required): Maximum targeted missing-fact questions returned.
- `ruleId` (string, required): Exact event-recurring ruleId returned by resolve_company_plan.
- `sourceObservedAt` (string): Required for expiring evidence-backed event facts.
- `sourceRef` (string, required): Stable reference reused unchanged when promoting staged candidates.
- `sourceType` (string, required)
- `subjectId` (string): Required for subject-scoped event rules; omitted for company rules.
- `trustLevel` (integer)

### `upload_operating_evidence` (~256 tokens)

Store exact caller-supplied evidence bytes in the active company's private canonical evidence prefix and return the server-computed SHA-256 needed by record_operating_evidence. Use only when the client has supplied the actual base64 file bytes; never invent bytes from a description. Browser/desktop clients should use POST /operating/evidence/upload for files larger than the MCP limit. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string): corply_companies.id. May be omitted only when the active organization has exactly one company.
- `contentType` (string)
- `dataBase64` (string, required): Canonical RFC 4648 base64 for the exact file bytes, without a data-URL prefix.
- `fileName` (string, required)

### `record_operating_evidence` (~453 tokens)

Record a company-owned evidence artifact, then freshly resolve the plan. Evidence is not task completion by itself; attach its id when transitioning a work item. For new files, call upload_operating_evidence (or the authenticated multipart upload endpoint) and use its server-returned filePath/fileHash. Founder-uploaded documents remain claims: use submit_operating_fact_evidence to bind and queue them for operator review. Only an operator may directly promote an evidence-confirmed fact. Professional determinations require named reviewer credentials. A guidance link or model assertion is never professional evidence. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string): corply_companies.id. May be omitted only when the active organization has exactly one company.
- `covers` (array): Exact completionEvidence labels from workItemId that this artifact proves.
- `description` (string)
- `factId` (string): Candidate/current fact assertion this evidence substantiates. Unbound evidence cannot promote a fact.
- `fileHash` (string): Full SHA-256 of the stored bytes; Corply downloads and verifies it server-side.
- `filePath` (string): Immutable object in corply-documents under operating-evidence/<orgId>/<companyId>/. Copy mutable formation aliases through upload_operating_evidence first.
- `itemLimit` (integer, required): Maximum items returned per actionable/blocked/waiting section.
- `kind` (string, required)
- `metadata` (object): Non-secret artifact metadata.
- `professional` (object)
- `questionLimit` (integer, required): Maximum targeted missing-fact questions returned.
- `title` (string, required)
- `workItemId` (string): Required when covers is non-empty; prevents reusing self-declared labels across occurrences.

### `submit_operating_fact_evidence` (~261 tokens)

Submit one founder-provided document for an evidence-confirmed operating fact. This stages the exact typed assertion, binds the server-verified immutable artifact, and creates a durable operator-review claim. Submission never makes the fact canonical and the resolver will continue to ask for it until an operator approves the exact claim. filePath/fileHash must come from upload_operating_evidence. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `companyId` (string, required)
- `factKey` (string, required)
- `fileHash` (string, required)
- `filePath` (string, required)
- `idempotencyKey` (string, required)
- `sourceObservedAt` (string, required)
- `sourceReference` (string, required)
- `subjectId` (required)
- `title` (string, required)
- `value` (required)

### `record_existing_completion` (~290 tokens)

Record evidence that the company completed one exact materialized work occurrence outside Corply. The command pins rule/version/subject/occurrence, requires a durable idempotency key and explicit attestation, and routes the immutable claim to automatic, operator, or professional review. This tool never marks the work completed merely because evidence was submitted; use the normal fact and work-transition tools only after the returned review and remaining evidence/outcome gaps are resolved. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input parameters:

- `attestation` (object, required)
- `claimedOutcome` (object, required)
- `companyId` (string, required)
- `evidence` (array, required)
- `idempotencyKey` (string, required)
- `occurrenceKey` (string, required)
- `provenance` (object)
- `ruleId` (string, required)
- `ruleVersion` (string, required)
- `source` (object, required)
- `subjectId` (required)
- `workItemId` (string, required)

### `transition_operating_work_item` (~261 tokens)

Transition one materialized work occurrence by workItemId, then freshly resolve the company plan. Completion is rejected until attached company evidence covers every requirement and required human/professional boundaries. Legal, tax, regulatory, provider, and contractual requirements cannot be waived; change facts only with truthful evidence. Prerequisite: authenticated active organization access plus every prerequisite stated above. Canonicality: invokes the shared backend action; refresh get_company_briefing after material change. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: obtain fresh, explicit user confirmation before calling.

Input parameters:

- `companyId` (string): corply_companies.id. May be omitted only when the active organization has exactly one company.
- `evidenceEventIds` (array)
- `expectedFromStatus` (string): Optimistic-concurrency guard from the latest plan.
- `idempotencyKey` (string)
- `itemLimit` (integer, required): Maximum items returned per actionable/blocked/waiting section.
- `questionLimit` (integer, required): Maximum targeted missing-fact questions returned.
- `reason` (string)
- `toStatus` (string, required)
- `workItemId` (string, required)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/corply-dev-corply/corply#diagnostics

## Score history

- 2026-08-03: 70
- 2026-08-02: 69
- 2026-08-01: 69
- 2026-07-31: 68
- 2026-07-30: 61
- 2026-07-29: 61
- 2026-07-28: 61
- 2026-07-27: 59
- 2026-07-26: 59

## Links

- Remote endpoint: https://corply.dev/mcp
- Repository: https://github.com/corply-dev/corply-plugin
- Website: https://corply.dev/
- Changelog RSS feed: https://verifymcp.io/servers/corply-dev-corply/corply/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/corply-dev-corply/corply/changelog.json
- HTML version of this page: https://verifymcp.io/servers/corply-dev-corply/corply