corply
Server Details
Incorporate a Delaware C-Corp from your agent — docs, cofounder e-sign, human-reviewed filing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 18 of 18 tools scored. Lowest: 2.6/5.
Each tool has a clearly distinct purpose: payment, validation, document generation, signatures, invites, post-incorporation tasks, memory, and identity. Even overlapping tools like invite_cofounders and invite_member serve different stages (post-payment vs. general org invite), and nudge_signer is specific to reminders.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., await_payment, generate_documents, save_application), making the tool surface predictable and easy to navigate.
18 tools is well-scoped for a complex domain like company incorporation, covering every step from payment to post-incorporation tasks without being excessive. Each tool earns its place.
The tool set provides end-to-end coverage: payment, validation, document generation, signatures, invites, status tracking, post-incorporation tasks, and memory. The only noted gap (Delaware filing) is explicitly called out, and the workflow guides the agent through each step.
Available Tools
18 toolsawait_paymentAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| formationId | Yes | ||
| maxWaitSeconds | No | Seconds to wait before returning (ceiling ~10s — the gateway kills longer-held requests). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries the burden. It discloses the waiting mechanism (~8 seconds, gateway kills longer requests), possible return statuses, loop requirement, and preconditions (e.g., need request_payment for unpaid). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but every sentence adds value. It is front-loaded with the main purpose. Minor redundancy (e.g., 'call it repeatedly' restated) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains return values (status with retryAfterSeconds) and covers all states with next actions. It also references sibling tools appropriately. For a tool with 2 parameters, this is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with only maxWaitSeconds described. The description adds context for maxWaitSeconds (ceiling ~10s, gateway killing) and implies formationId is the session identifier. It does not explicitly describe formationId's role but provides enough context from usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for payment to land and returns status. It distinguishes from siblings by warning not to call request_signature, invite_cofounders, or submit_for_formation before payment is confirmed, and references request_payment for expired/unpaid states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call in a loop until 'paid', provides retryAfterSeconds, and specifies alternate actions for 'expired' and 'unpaid'. It also warns about gateway killing long-held requests and suggests appropriate maxWaitSeconds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_documentsAInspect
Requires status 'ready' (run validate_application first). Freezes the formation and renders its documents as immutable finals — 4 company docs (Certificate of Incorporation, Bylaws, Action of Incorporator, Initial Board Consent), one Restricted Stock Purchase Agreement per founder, one Section 83(b) Election per founder electing 83(b), and the IRS SS-4 (EIN application) preparation sheet (unsigned — no signature required). Editing the application with save_application AFTER this reopens the formation: it supersedes the generated documents and any signatures already collected, and everyone must re-review and re-sign the re-generated set.
| Name | Required | Description | Default |
|---|---|---|---|
| formationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it freezes the formation, makes documents immutable, and warns that editing reopens and invalidates prior signatures. It also notes the unsigned SS-4. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and front-loaded with the prerequisite. It is somewhat long but each sentence adds value. Minor room for tightening, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, no output schema, and detailed description of documents and side effects, the description is complete for an AI agent to understand the tool's behavior and consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (one undocumented parameter 'formationId'), but the description implicitly makes clear that formationId identifies the formation to act on. While not explicitly described, the meaning is obvious from context. Baseline 4 applies for no parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool freezes the formation and renders documents as immutable finals, listing specific documents. This specifies the verb (generate) and resource (documents) distinctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the prerequisite (status 'ready', run validate_application first) and warns against editing after generation, which explains when to use and what not to do. It implies when not to use (if status is not ready) and what alternatives exist (validate_application before this).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_orgAInspect
Return the caller's organization and its companies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states what is returned, but does not mention authentication requirements, potential errors (e.g., no org), or other behaviors like read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the verb and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides minimal but essential information. However, it lacks details on error handling, response structure, or edge cases, leaving some gaps for a comprehensive understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% schema description coverage, so baseline is 4. The description does not need to explain parameters, and it adds no extra param info beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and resource 'the caller's organization and its companies', clearly stating what the tool does. It distinguishes from sibling tools like whoami (returns user info) and get_status (returns status), which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving organization info but provides no explicit guidance on when to use this tool versus alternatives, such as whoami for user details or get_status for status. No when-not-to-use scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statusAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | ||
| formationId | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description details the return fields and importantly tells agents to rely on nextStep. Missing explicit read-only hint but implied by 'return'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense sentence with all key info, but could be structured (e.g., bullet points for fields). No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description thoroughly lists return fields. However, parameter semantics are lacking, and no error/edge-case guidance provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description does not explain companyId or formationId beyond the phrase 'for a company (or its latest formation)', leaving agents to guess parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a clear verb and resource: 'Return the formation status for a company (or its latest formation)' and lists specific fields, distinguishing it from siblings like get_org or await_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to 'trust nextStep over your own inference', but does not mention when not to use this tool or compare with alternatives among the 17 siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invite_cofoundersAInspect
Requires the incorporation fee to be PAID first (request_payment → await_payment). One step after documents are generated: invite every OTHER listed founder. Each cofounder gets a single email with (a) a web link to review & sign and (b) instructions to install the Corply plugin and join this organization. Idempotent — re-running refreshes links without duplicating invites. Only run when the lead explicitly asks. Sign links are delivered directly to each cofounder — they are not shown here unless their email fails.
| Name | Required | Description | Default |
|---|---|---|---|
| formationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It discloses required dependency on payment, idempotency, email content, and delivery details. This is comprehensive for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each providing essential information without redundancy. Critical info (prerequisite, action, behavior) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple input schema (1 param) and no output schema or annotations, the description covers prerequisites, behavior, idempotency, and delivery. It does not explain return values, but that is acceptable for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It implies formationId context but does not explicitly explain the parameter. The description adds value by placing the parameter in the overall workflow, but the semantics are not fully detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool invites cofounders after payment and document generation, distinguishing it from siblings like invite_member. The verb 'invite' and resource 'cofounders' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies prerequisites (payment, document generation) and when to run (only when lead asks). It implies alternatives by mentioning other steps like request_payment, but does not explicitly list when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invite_memberCInspect
Invite a cofounder to this organization by email. They join from their own Claude Code by signing in with that email.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | ||
| Yes | |||
| companyId | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It explains that the invitee joins by signing in with their email, but fails to mention side effects (e.g., email sent, permissions required, whether the invite can be revoked). This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The action is stated first, making it easy to scan. There is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, no output schema), the description only covers the basic action. Missing elements include context about organization membership, how the invite is delivered, response format, and error handling. This leaves significant gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no information about any of the three parameters (email, role, companyId). The only clue is 'by email' which loosely relates to the 'email' parameter. The purpose and format of 'role' and 'companyId' remain completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('invite') and resource ('cofounder') with a specific method (by email). It is distinct from the sibling 'invite_cofounders' which may have a different scope, but the description does not explicitly differentiate between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding a cofounder but provides no guidance on when to use this tool versus alternatives like 'invite_cofounders'. There is no mention of prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mark_task_doneAInspect
Report one of YOUR post-incorporation tasks as done (e.g. 'I mailed my 83(b) election') with an optional note. Corply's team verifies and completes it — status becomes 'pending review'. Only works for tasks assigned to the founder.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| stepKey | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description reveals that the status becomes 'pending review' and Corply's team verifies it. This gives insight into post-invocation behavior, though it doesn't disclose destructive effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Exactly two sentences, front-loaded with purpose, no extraneous information. Highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's effect (pending review) and notes optionality, but lacks explanation for the required stepKey parameter and does not describe return values or output format. Adequate for a simple tool but incomplete in parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains 'note' is optional and gives an example, but does not clarify 'stepKey'. The schema provides no additional clarity, leaving the agent guessing about what stepKey is.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports a task as done with an optional note. It distinguishes from siblings by specifying it's for tasks assigned to the founder, but could be more precise about the 'done' state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it only works for tasks assigned to the founder, providing a clear usage context. However, it does not discuss when not to use it or compare with alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nudge_signerAInspect
Re-send the signature reminder email to a cofounder who hasn't signed yet. Only when the lead asks.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| formationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates this tool sends an email (a write operation) and targets a cofounder who hasn't signed, but doesn't disclose potential errors, rate limits, or what happens if already signed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and key condition. No extraneous information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details on return values, error scenarios, or parameter semantics. For a tool with no output schema and no annotations, the description is too minimal to be fully complete given the parameter gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation for the 'email' and 'formationId' parameters. It only mentions the general purpose without connecting to the specific parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 're-send' and resource 'signature reminder email to a cofounder', making the action specific. It also distinguishes from sibling tools like 'request_signature' and 'invite_cofounders' by specifying this is a reminder sent only when the lead asks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Re-send the signature reminder email to a cofounder who hasn't signed yet. Only when the lead asks.' This implies not for initial requests or other signers, but does not name alternative tools for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallBInspect
Search the organization's context memory + Corply reference KB for relevant facts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| includeGlobal | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It indicates a search operation (presumably read-only) but does not explicitly state idempotency, side effects, or authorization requirements. The description is adequate for a simple retrieval tool but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded, containing no extraneous information. Every word serves the purpose of stating what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameter explanations and no output schema, the description is incomplete for a tool with 2 parameters. It provides general purpose but leaves critical details about input meanings and return values unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of the parameters ('query' and 'includeGlobal') beyond what the schema specifies (types). With 0% schema coverage, the description should add meaning, but it fails to do so, leaving the agent to infer parameter semantics from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for relevant facts from two specific sources: the organization's context memory and the Corply reference KB. It uses a specific verb ('Search') and identifies the resources, making its purpose distinct from siblings that might store or retrieve information differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'remember' or 'whoami'. The description implies usage for fact retrieval from the specified sources but does not provide exclusions or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_signatureAInspect
Record a binding e-signature (full ESIGN/UETA audit bundle). CALLER GATE: only call after the actual signer — the live participant in this session — has been shown THIS specific document and given a fresh, in-the-moment affirmative act adopting it. Never act on standing/blanket/prior-session consent, never sign on behalf of an absent cofounder (they sign from their own session), and never set esignConsent:true unless the signer just affirmatively signed. After ONE affirmative act in which the signer lists all the documents being signed, call this once per pending signatureId in that same turn.
| Name | Required | Description | Default |
|---|---|---|---|
| contentHash | Yes | ||
| signatureId | Yes | ||
| esignConsent | Yes | ||
| signedLegalName | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool records a binding signature with legal implications and warns against common mistakes (e.g., blanket consent, signing for absent cofounders). However, it omits details on success/failure response, idempotency, or rate limits, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and uses 'CALLER GATE' to structure crucial usage constraints. However, it is verbose, repeating 'affirmative act' multiple times and could be tightened slightly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% parameter description coverage, the description adequately covers behavioral constraints and usage guidelines. However, it lacks parameter details for half the parameters and does not describe return values or error conditions, leaving some gaps for a tool with 4 required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions signatureId (pending signatureId) and esignConsent (never set true unless just affirmatively signed), adding meaning for these. But it does not describe contentHash or signedLegalName, leaving two parameters undocumented. This partial coverage earns a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a binding e-signature with an audit bundle, distinguishing it from sibling tools like request_signature (which likely sends a signing request) and nudge_signer (reminders). The verb 'record' and resource 'e-signature' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit conditions for when to call (after the signer has seen the document and given an affirmative act) and when not to (never on standing consent, never for absent cofounder, never without affirmative consent). It also specifies to call once per pending signatureId after one affirmative act, offering clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
redeem_inviteAInspect
Join an organization with an invite join code. Ask the user to confirm first ('Join {company} as a cofounder?') — joining switches your active organization.
| Name | Required | Description | Default |
|---|---|---|---|
| joinCode | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool asks for user confirmation and switches the active organization. However, it could be more explicit about side effects like losing access to the previous organization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and contains no unnecessary words. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers main behavior (joining, confirmation, org switch). It could mention success/failure outcomes but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and only one parameter ('joinCode'). The description merely restates the parameter name ('invite join code') without adding format, length, or example. It barely adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Join an organization') with a specific verb ('redeem') and resource ('invite join code'). It also distinguishes from sibling tools like 'invite_cofounders' and 'invite_member', which are for inviting rather than joining.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when user has a join code) and includes a user-confirmation step, but it does not explicitly state when not to use this tool or provide alternatives. It lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberBInspect
Persist a durable decision/fact into the organization's context memory.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions 'durable' but lacks details on overwrite behavior, idempotency, or limits, leaving behavioral expectations unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 10 words is extremely concise and front-loaded, but may slightly sacrifice completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema or annotations, the description omits return behavior (e.g., success indicator, ID) and integration details, making it minimally adequate for a one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds context that the 'text' parameter should contain a decision or fact, but with 0% schema coverage and no format/length constraints, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('persist') and the resource ('decision/fact into organization's context memory'), distinguishing it from sibling 'recall' which is likely for retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for storing decisions or facts but provides no explicit guidance on when to use versus alternatives like 'recall' or other creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_paymentAInspect
MANDATORY before any signing: create (or reuse) the Stripe Checkout link for the one-time Corply incorporation fee ($600; promo codes accepted at checkout). Show the returned checkoutUrl to the founder in chat as a markdown link — they 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.
| Name | Required | Description | Default |
|---|---|---|---|
| formationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains key behaviors: payment amount ($600), promo codes accepted, lead founder pays once, safe to re-call (reuses session). Does not cover authentication or error scenarios, but sufficient for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with key constraint upfront ('MANDATORY before any signing'). Each sentence adds useful information, though slightly verbose; could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description covers purpose, usage, safety, and context. It lacks explanation of return format but mentions showing checkoutUrl.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (formationId) with no schema description. The description does not explain what formationId represents or how to obtain it, leaving agents without necessary context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates/reuses a Stripe Checkout link for the Corply incorporation fee and shows the URL to the founder. It distinguishes from sibling tools like request_signature and await_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'MANDATORY before any signing' and clarifies that only the lead founder pays once, cofounders never pay, and editing documents doesn't re-charge. Provides clear when-to-use and when-not-to-use context, though doesn't name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_signatureAInspect
Requires the incorporation fee to be PAID first (request_payment → await_payment). The ONE consent ceremony — it covers ALL documents in this formation, not one signature per document. Returns the disclaimer plus a review link per signer; present each reviewUrl as a markdown link so it's clickable in chat. Idempotent — safe to re-call; it reuses pending signature requests instead of duplicating them.
| Name | Required | Description | Default |
|---|---|---|---|
| formationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses idempotency, the return of a disclaimer and review links, and the prerequisite of prior payment. It does not cover authentication, rate limits, or error handling but provides sufficient behavioral context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written with no superfluous content. It front-loads the critical prerequisite, then explains the key behavior, return values, and idempotency in a logical sequence. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required param, no output schema), the description covers prerequisites, core behavior, and idempotency. It lacks explicit error scenarios (e.g., what happens if payment is not made), but overall provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not explicitly define formationId or its format. Although the context implies it refers to a formation entity, the agent receives no direct guidance on the parameter's purpose or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool requests signatures for a business formation, emphasizing it's a single consent ceremony that covers all documents. It distinguishes itself from siblings like record_signature and nudge_signer by being the primary signature step and not per-document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires the incorporation fee to be paid first, referencing the request_payment→await_payment sequence. Also notes idempotency, encouraging safe re-calls. However, it does not explicitly compare to sibling tools like nudge_signer or explain when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_applicationAInspect
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. Returns { formationId, nextStep }.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| companyId | No | corply_companies.id (from get_org). OMIT it — the server auto-attaches the org's company. NEVER pass a formationId here. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses deep-merge upsert behavior, partial payload safety, and return shape. Missing details on idempotency, concurrency, or side effects, but overall adequate for a basic save operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key behavior, no wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nested object schema, no output schema, and no annotations, description covers core behavior and return type. Could add more about usage context relative to siblings, but sufficient for a save operation with 2 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds 'deep-merge upsert' context for the 'data' parameter beyond schema. For 'companyId', description gives clear instruction to omit it. Schema coverage is 50%, so description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a 'deep-merge upsert' of a 'structured formation application', using specific verbs and resources. Differentiates from siblings like validate_application and submit_for_formation by its incremental save behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for incremental saves but lacks explicit guidance on when to use versus siblings (e.g., validate_application for validation, submit_for_formation for final submission). No exclusion criteria or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_for_formationAInspect
Requires the incorporation fee to be PAID first (request_payment → await_payment). Hand the fully-signed formation to the human filing pipeline. Does NOT file with Delaware.
| Name | Required | Description | Default |
|---|---|---|---|
| formationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility. It reveals key behaviors: the need for payment, the handoff to a human pipeline, and the explicit negation of Delaware filing. This level of disclosure is sufficient for an agent to understand the tool's non-destructive but interim nature, though more detail on post-submission tracking could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that pack essential information (prerequisites, action, limitation) without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and key constraints but omits information about the tool's return value or any follow-up actions (e.g., what happens after handoff, how to track status). Given the low complexity and absence of an output schema, it meets a minimum viable threshold but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required parameter 'formationId' with no description (0% schema coverage). The tool description does not explain what formationId represents or where to obtain it, leaving the agent with no guidance on how to populate the parameter. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: handing the fully-signed formation to the human filing pipeline. It also explains what it does not do (file with Delaware) and ties it to a specific resource ('formation'), making the purpose unambiguous and distinct from siblings like request_payment and await_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly specifies a precondition (fee must be paid first, with a reference to sibling tools request_payment and await_payment) and an exclusion (does not file with Delaware). This provides clear guidance on when and how to use the tool, though it stops short of listing all alternatives or explicitly stating when to use this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_applicationAInspect
Validate the formation application; returns missing fields (dotted paths). Corply does NOT check Delaware name availability — the founder must verify it themselves at nameAvailability.verifyUrl before generating documents. Promotes the formation to 'ready' when complete.
| Name | Required | Description | Default |
|---|---|---|---|
| formationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: does not check name availability, promotes formation to 'ready'. No annotations provided, so description carries full burden; covers main side effects adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences pack purpose, crucial exception, and outcome without waste. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple validation tool with one param and no output schema, description covers needed context: what it does, what it returns, and a critical caveat. Missing some detail on return format, but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'formationId' has no schema description (0% coverage). Description does not explicitly define it, but tool name and context make it unambiguous. Could add format or example for clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'validate' with specific resource 'formation application'; returns missing fields with dotted paths. Distinct from siblings like 'submit_for_formation' and 'generate_documents'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that Corply does not check Delaware name availability, indicating when not to rely on this tool and directing to external verification. Also notes it promotes to 'ready', implying correct usage sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiAInspect
Return the resolved caller identity (user + org). If pendingInvites is non-empty, tell the user and OFFER to join (confirm before redeem_invite).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that if pendingInvites is non-empty, the agent should tell the user and offer to join, which is a behavioral trait beyond a simple identity lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no extraneous words. The instruction about pending invites is placed after the main purpose, which is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description sufficiently explains what the tool returns and a key conditional behavior. It could mention the output format but is not required for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema covers 100%. The description adds value by explaining the output (identity) and conditional behavior, going beyond what the empty schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'resolved caller identity (user + org)', and distinguishes itself by adding conditional behavior for pending invites, which relates to sibling tool redeem_invite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for use (when identity is needed) and a specific conditional instruction about pending invites, guiding the agent to confirm before calling redeem_invite. However, it doesn't explicitly list scenarios where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!