Skip to main content
Glama

Corply — Start and run your company

by io.github.corply-dev
OverviewDiscussionsAdmin

Sign a formation document bundle

sign_bundle
Destructive

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 fresh explicit electronic-signature consent IN THIS CHAT after you present their confirmed full legal name and the complete server authorizationDisclosure. Accept consent in their own words; never require a prescribed sentence. A review link click or 'reviewed' is not consent. If they sign personally on the web, refresh status instead of calling this tool again. 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 pre-filing Founder Formation Authorization also grants narrow advance authority: 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 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
bundleIdYes
formationIdYes
esignConsentYes
_corply_contextNo
signedLegalNameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / _corply_context / description
      Removed value: -"Echo context_engineering.context_session from the prior Corply result."
  2. 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"
+}
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark this as non-read-only, open-world, and destructive, but the description adds substantial behavioral context: the consent ceremony, caller gate, 83(b) advance-authority behavior, TIN link handling, idempotency and canonicality guidance, and confirmation boundary. It discloses what must happen before, during, and after the call beyond the structured annotations.

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

Conciseness4/5

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

The description is long, but it is front-loaded with the core purpose and caller gate, then organized with explicit headings for prerequisites, canonicality, idempotency, and confirmation boundaries. Some consent-related guidance is repeated, which keeps it from a perfect score, but most sentences carry operational weight for a high-stakes signing tool.

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, destructive, open-world signing operation with no output schema, the description is unusually complete. It covers prerequisites, caller eligibility, consent standards, edge cases like 83(b) auto-execution, post-call TIN handling, retry behavior, and confirmation requirements. No additional description text is needed for an agent to call it correctly.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains that bundleId is the opaque server-issued bundle from get_status or request_signature, signedLegalName is the confirmed full legal name, and esignConsent reflects fresh explicit consent. However, formationId and the nested _corply_context object are not explained at all, leaving meaningful gaps for a 5-parameter tool.

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 states a specific verb and resource: 'Record one binding ESIGN/UETA consent for the exact server-issued bundle returned by get_status or request_signature.' It clearly distinguishes this tool from sibling tools like get_status, request_signature, and web-based signing. An agent can identify the action and required source artifact 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?

It gives an explicit caller gate: only the live signer may call it, after reviewing every listed document and giving fresh explicit consent in this chat. It also states when not to call it ('If they sign personally on the web, refresh status instead') and forbids reusing prior-session consent or signing for an absent cofounder. Alternatives and exclusions are unambiguous.

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