Skip to main content
Glama

Corply — Start and run your company

by io.github.corply-dev
OverviewDiscussionsAdmin

Import an existing company

import_company

Import an existing Delaware C-Corp, preserving work already done elsewhere. When the founder has formation documents, use create_import_intake instead so Corply reads the details from them. Omit companyId to create a separate company (or use your sole untouched first-account draft); provide companyId only to resume that company's import. Collect exact legal name, state/type, formation date, optional EIN and state file number, founder count, and a stable requestId. This creates a company import, not a new state formation. Confirm before creating. Ask one multiple-choice question at a time using each item's question and options. Never assume existing documents or completion. As soon as the user has documents, present and, if your client can open URLs, open the uploadUrl while continuing the questions. Also offer to import a public HTTPS PDF link pasted in chat. Documents stay pending until Corply admin accepts them. EIN format and name availability are only screening, not verification. Never pay or sign for the founder. Use checkoutUrl for their personal payment authorization. Once the company exists, also ask whether the founder has a logo to add (set_company_logo) and whether it already uses an email domain (for example you@theircompany.com); if so, use inspect_email_domain and connect_email_domain so its invoices and company notices send from that domain; both questions are optional and never block the import. 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: 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 Schema

TableJSON Schema
NameRequiredDescriptionDefault
einNo
choicesNo
companyIdNo
legalNameYes
requestIdYes
entityTypeYes
founderCountNo
jurisdictionYes
formationDateNo
_corply_contextNo
stateFileNumberNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / entityType / const
      Added value: +"c_corp"
    • removedInput schema / properties / entityType / enum
      Removed value: -[
-  "c_corp",
-  "llc"
-]
    • addedInput schema / properties / jurisdiction / const
      Added value: +"US-DE"
    • removedInput schema / properties / jurisdiction / enum
      Removed value: -[
-  "US-DE",
-  "US-FL"
-]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover readOnly=false/destructive=false/openWorld=true; the description adds substantial behavioral facts beyond them: documents stay pending until admin acceptance, EIN/name checks are screening not verification, never pay or sign for the founder (use checkoutUrl), idempotency/retry guidance, and canonicality handling. It also warns against assuming documents or completion exist.

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 core import workflow is front-loaded and valuable, but the text is very long and pads onto generic boilerplate ('Canonicality', 'Idempotency', 'Confirmation boundary') that reads like appended policy rather than tool-specific guidance. The 'Confirm before creating' instruction sits awkwardly against the boilerplate 'no additional confirmation is needed' clause.

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

Completeness4/5

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

For an 11-parameter, nested-object mutation with no output schema, the description covers the workflow, post-import follow-ups (logo, email domain), and safety constraints well. Remaining gaps are the undocumented choices enum semantics and quantity, plus the internally muddled confirmation language.

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

Parameters4/5

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

With 0% schema description coverage, the description compensates well: it defines the meaning of companyId (omit vs. resume), legalName ('exact legal name'), jurisdiction/entityType, formationDate, EIN, state file number, founderCount, and the stable requestId, and describes the one-question-at-a-time choices flow. It does not explain the choices enum values (have/corply/not_applicable) or quantity, so it falls short of complete coverage.

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?

Opens with a specific verb+resource+scope ('Import an existing Delaware C-Corp') and explicitly disambiguates from the sibling path: 'When the founder has formation documents, use create_import_intake instead.' It also clarifies what it is not ('This creates a company import, not a new state formation'), which lets an agent separate it from adopt_existing_company and start_company_draft.

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?

Gives explicit selection and exclusion rules: use create_import_intake if documents exist, otherwise this; omit companyId to create a separate company vs. provide it to resume an import. Prerequisites (authenticated active company access) and confirmation boundary are also stated, leaving little to inference.

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