Skip to main content
Glama

Corply — Start and run your company

by io.github.corply-dev
OverviewDiscussionsAdmin

Prepare the formation fee checkout

request_payment

After every required signature, when nextStep is request_payment: prepare one canonical checkout for formation plus the first required ongoing-plan period. Ask monthly versus annual once, then read get_status with that billingCadence and show payment.founderSummary exactly as written (dueToday, every later line, howToPay); never calculate prices yourself. The cadence choice is not consent. Phone, work email and domain are selected by default; never suggest removing them. If the founder explicitly asks to remove any before this first checkout, read get_status again with the current billingCadence and removedOptionalServices, show the updated exact summary, and obtain fresh consent. Then call request_payment with annualBillingAccepted=true and the same billingCadence and removedOptionalServices. Do not use manage_company_billing before activation; it changes an active plan after settlement. Annual means 20% off Corply service fees; provider and government charges are not discounted. There is no formation-only or recurring opt-out. The checkout saves the card for renewals and, when the tax authorization appears, one variable Delaware government charge annually after exact advance notice. Corply Tax requires a card; never accept payment credentials in chat. Payment settlement is mandatory before formation filing or service provisioning. For an amendment balance, show the server summary and preserve historical terms. A disclosureBlocker requires Corply reconciliation. Any billing manager may pay once per company. Safe retries return the same checkout for unchanged terms; a changed unpaid cadence or service selection replaces it. Show checkoutUrl as Pay now. If payments are unavailable, report the recoverable error and never invent a payment route. Prerequisite: authenticated active company access plus every prerequisite stated above. Canonicality: invokes the shared backend action; trust the returned actual_tool_output and context_engineering instead of adding a state-recovery call. 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 Schema

TableJSON Schema
NameRequiredDescriptionDefault
formationIdYes
billingCadenceYesRequired choice for a new formation: monthly or annual. Annual includes 20% off Corply service fees. Obtain the preference once, preview it through get_status, then obtain fresh consent to that exact summary.
_corply_contextNo
annualBillingAcceptedYesLegacy field name: pass true only after the founder explicitly accepts the entire payment.founderSummary for the selected billingCadence: today's exact formation and first plan period, recurring plan, saved card, and the annual Delaware government charge when shown. Never infer acceptance from a request to incorporate or pay, a cadence choice, or silence.
removedOptionalServicesNoUse only when the founder explicitly requested these optional services be removed before first checkout and accepted the exact get_status summary previewed with the same billingCadence and identical removedOptionalServices. Never suggest removal. Omit to keep phone, email, and domain selected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / annualBillingAccepted / description
      Previous value: -"Legacy field name: pass true only after the founder explicitly accepts payment.founderSummary for their selected annualRenewal. With 'none' they accept only today's purchase and first-year coverage, with no recurring enrollment or payment method saved for future charges. Other modes disclose their renewal charges and saved-method terms. Never infer acceptance from a general request to incorporate/pay or from a preference choice."New value: +"Legacy field name: pass true only after the founder explicitly accepts the entire payment.founderSummary for the selected billingCadence: today's exact formation and first plan period, recurring plan, saved card, and the annual Delaware government charge when shown. Never infer acceptance from a request to incorporate or pay, a cadence choice, or silence."
    • removedInput schema / properties / annualRenewal
      Removed value: -{
-  "description": "Use the founder's selected choice. 'none': first year only, no renewal enrollment or payment method saved for future charges. 'automatic': annual renewal on the saved method. 'tax_date': automatic annual renewal on the annual tax date. 'approval_required': method saved, but each renewal needs approval. If preference is missing, offer payment.founderSummary.renewalChoices, then get_status with the choice for its exact disclosure. Omitted means automatic only for legacy-client compatibility. An amendment balance preserves the existing renewal setting.",
-  "enum": [
-    "automatic",
-    "approval_required",
-    "tax_date",
-    "none"
-  ],
-  "type": "string"
-}
    • addedInput schema / properties / billingCadence
      Added value: +{
+  "description": "Required choice for a new formation: monthly or annual. Annual includes 20% off Corply service fees. Obtain the preference once, preview it through get_status, then obtain fresh consent to that exact summary.",
+  "enum": [
+    "monthly",
+    "annual"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / removedOptionalServices
      Added value: +{
+  "description": "Use only when the founder explicitly requested these optional services be removed before first checkout and accepted the exact get_status summary previewed with the same billingCadence and identical removedOptionalServices. Never suggest removal. Omit to keep phone, email, and domain selected.",
+  "items": {
+    "enum": [
+      "phone",
+      "email",
+      "domain"
+    ],
+    "type": "string"
+  },
+  "maxItems": 3,
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "formationId",
-  "annualBillingAccepted"
-]New value: +[
+  "formationId",
+  "annualBillingAccepted",
+  "billingCadence"
+]
  2. Changed3 schema fields changed
    • changedInput schema / properties / annualBillingAccepted / description
      Previous value: -"Pass true only after the founder explicitly accepts the exact server-returned due-today amount and fixed annual registered-agent renewal, beginning after the included first year, under their chosen annualRenewal mode, and understands Corply keeps the payment method on file through Corply Pay (charged for renewals automatically, or only after they approve each renewal in approval_required mode). Never infer acceptance from a general request to incorporate or pay."New value: +"Legacy field name: pass true only after the founder explicitly accepts payment.founderSummary for their selected annualRenewal. With 'none' they accept only today's purchase and first-year coverage, with no recurring enrollment or payment method saved for future charges. Other modes disclose their renewal charges and saved-method terms. Never infer acceptance from a general request to incorporate/pay or from a preference choice."
    • changedInput schema / properties / annualRenewal / description
      Previous value: -"How the fixed annual registered-agent renewal is handled after the included first year. 'automatic' (the default when omitted): renews every year until cancelled in Settings → Billing, charged to the saved card or bank account. 'approval_required': the card or bank account stays on file, but no renewal is ever charged until the founder approves it (Corply emails about 35 and 18 days before the included year ends); without approval coverage ends and the company must appoint another registered agent. Omit or pass 'automatic' unless the founder asked for approval before each renewal. An amendment balance keeps the existing renewal setting and ignores this field."New value: +"Use the founder's selected choice. 'none': first year only, no renewal enrollment or payment method saved for future charges. 'automatic': annual renewal on the saved method. 'tax_date': automatic annual renewal on the annual tax date. 'approval_required': method saved, but each renewal needs approval. If preference is missing, offer payment.founderSummary.renewalChoices, then get_status with the choice for its exact disclosure. Omitted means automatic only for legacy-client compatibility. An amendment balance preserves the existing renewal setting."
    • changedInput schema / properties / annualRenewal / enum
      Previous value: -[
-  "automatic",
-  "approval_required"
-]New value: +[
+  "automatic",
+  "approval_required",
+  "tax_date",
+  "none"
+]
  3. Changed6 schema fields changed
    • removedInput schema / properties / _corply_context / description
      Removed value: -"Echo context_engineering.context_session from the prior Corply result."
    • addedInput schema / properties / annualBillingAccepted
      Added value: +{
+  "const": true,
+  "description": "Pass true only after the founder explicitly accepts the exact server-returned due-today amount and fixed annual registered-agent renewal, beginning after the included first year, under their chosen annualRenewal mode, and understands Corply keeps the payment method on file through Corply Pay (charged for renewals automatically, or only after they approve each renewal in approval_required mode). Never infer acceptance from a general request to incorporate or pay.",
+  "type": "boolean"
+}
    • addedInput schema / properties / annualRenewal
      Added value: +{
+  "description": "How the fixed annual registered-agent renewal is handled after the included first year. 'automatic' (the default when omitted): renews every year until cancelled in Settings → Billing, charged to the saved card or bank account. 'approval_required': the card or bank account stays on file, but no renewal is ever charged until the founder approves it (Corply emails about 35 and 18 days before the included year ends); without approval coverage ends and the company must appoint another registered agent. Omit or pass 'automatic' unless the founder asked for approval before each renewal. An amendment balance keeps the existing renewal setting and ignores this field.",
+  "enum": [
+    "automatic",
+    "approval_required"
+  ],
+  "type": "string"
+}
    • removedInput schema / properties / corplyMail
      Removed value: -{
-  "description": "Explicit renewal choice after disclosure. Defaults to none; annual is $119/year after 365 included days, monthly is $15/month.",
-  "enum": [
-    "annual",
-    "monthly",
-    "none"
-  ],
-  "type": "string"
-}
    • removedInput schema / properties / registeredAgent
      Removed value: -{
-  "description": "year_one = $449 total. lifetime = $799 total. Defaults to year_one.",
-  "enum": [
-    "year_one",
-    "lifetime"
-  ],
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "formationId"
-]New value: +[
+  "formationId",
+  "annualBillingAccepted"
+]
  4. Changed1 schema field changed
    • addedInput schema / properties / corplyMail
      Added value: +{
+  "description": "Explicit renewal choice after disclosure. Defaults to none; annual is $119/year after 365 included days, monthly is $15/month.",
+  "enum": [
+    "annual",
+    "monthly",
+    "none"
+  ],
+  "type": "string"
+}
  5. Changed1 schema field changed
    • addedInput schema / properties / _corply_context
      Added value: +{
+  "additionalProperties": false,
+  "dependentRequired": {
+    "receipt": [
+      "id"
+    ]
+  },
+  "description": "Echo context_engineering.context_session from the prior Corply result.",
+  "properties": {
+    "id": {
+      "maxLength": 200,
+      "minLength": 16,
+      "type": "string"
+    },
+    "receipt": {
+      "maxLength": 2048,
+      "minLength": 16,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  6. Changed1 schema field changed
    • addedInput schema / properties / registeredAgent
      Added value: +{
+  "description": "year_one = $449 total. lifetime = $799 total. Defaults to year_one.",
+  "enum": [
+    "year_one",
+    "lifetime"
+  ],
+  "type": "string"
+}
  7. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, but the description adds substantial behavioral context beyond that: the checkout saves a card for renewals, settlement is mandatory before filing, annual includes 20% off Corply service fees, a Delaware government charge may appear after notice, checkoutUrl should be shown as 'Pay now', and payments-unavailable errors must be reported honestly. It also discloses idempotency and canonicality behavior. There is no contradiction with the annotations.

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

Conciseness3/5

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

The content is front-loaded with the trigger and purpose, and most sentences carry operational weight. However, the description is a single dense block of several hundred words, mixing payment rules, prerequisite reminders, idempotency guidance, and confirmation boundaries without structural separation. A shorter, better-organized version could preserve the same essential guidance.

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 complex payment tool with no output schema, the description covers the full operational picture: prerequisites, consent requirements, optional service handling, billing cadence implications, retry/idempotency behavior, error handling, and what to show the user (founderSummary lines, checkoutUrl as 'Pay now'). The combination of annotations and this description leaves no critical gap for correct invocation or safe agent behavior.

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 60% schema description coverage, the description meaningfully supplements the schema for billingCadence, annualBillingAccepted, and removedOptionalServices: it explains the 20% annual discount, that annualBillingAccepted is a legacy field meaning explicit acceptance of the full summary, and that removedOptionalServices must only be used after an explicit founder request and fresh consent. It does not explain formationId or _corply_context, leaving minor gaps, but it carries the important consent-sensitive parameter semantics that the schema alone would not convey.

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 precise trigger ('when nextStep is request_payment') and a specific action ('prepare one canonical checkout for formation plus the first required ongoing-plan period'). It clearly distinguishes this tool from sibling manage_company_billing by stating that manage_company_billing must not be used before activation. An agent can identify both what the tool does and what it does not do without opening the schema.

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?

The description provides explicit when-to-use instructions ('After every required signature, when nextStep is request_payment'), alternative routing ('Do not use manage_company_billing before activation'), and prerequisite/confirmation boundaries. It also tells the agent exactly how to handle cadence choice, optional service removal, consent, and retry behavior. This is comprehensive routing guidance with no significant gaps.

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

All Corply — Start and run your 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