ein-llc

prepare_application

Prepare a provisional application and return the human claim URL. A human must claim and pay. This does not file, charge, or approve. An explicit operator request for existing formation assistance can attach a provisional non-actionable review to an eligible insufficient_information assessment. It does not recommend formation or start checkout.

Input Schema

Name	Required	Description
`assessment`	No
`operationId`	No	Optional caller idempotency key for a bound prepare. Trimmed and limited to 200 characters. When omitted, the key is prepare:{assessmentId}:{intendedEmailNormalized} and is specific to that assessment and recipient, and a missing key still recovers the application already bound to that assessment. An explicit key is not namespaced by assessment: it determines one durable application id. Reusing it for a different assessment returns 409 operation_identity_conflict. Supplying a different explicit key when this assessment is already bound returns the same 409, does not reserve that key, and returns no claim token. The same assessment with a different stored preparation returns 409 operation_payload_mismatch. Both leave the application, assessment, and authority unchanged and return no claim token. The same assessment, recipient, and stored preparation returns the original application and claim token and does not write again.
`preparation`	No
`assessmentId`	No	When present, the server-stored assessment is bound in one transaction with the application and authority. Same assessment plus intended email recovers the same application when the stored preparation matches. Facts and intended recipient must match the stored assessment. A different assessment cannot reuse an explicit operationId.
`intendedEmail`	No	Trimmed/lowercased; invalid or missing email produces an incomplete application, not a claim token.
`assessmentOutcome`	No	Fallback when preparation.assessmentOutcome is absent and no assessmentId/assessment is bound. Trimmed/truncated to 80 characters. Unknown values are refused. already_satisfied and not_needed_now are refused. insufficient_information cannot issue a claim token unless operatorRequestsExistingFormationAssistance is exactly true on an eligible stored assessment. A caller enum is not a server recommendation. Unbound allowed enum remains provisional advice, not actionable authorization.
`operatorRequestsExistingFormationAssistance`	No	Optional. Accepted only when exactly true. With a stored assessmentId, an eligible insufficient_information assessment (goal present, no US entity, EIN not already held, no affirmed provider entity or EIN-only requirement) can issue a provisional non-actionable claim. The flag does not affirm a provider requirement, recommend formation, or authorize filing, quote, or payment. String values are refused. Omitted on every other path, including required_for_selected_path.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 27, 2026

changedInput schema / properties / assessmentOutcome / description

Previous value: -"Fallback when preparation.assessmentOutcome is absent and no assessmentId/assessment is bound. Trimmed/truncated to 80 characters. Unknown values are refused. already_satisfied and not_needed_now are refused. insufficient_information cannot issue a claim token. Unbound allowed enum remains provisional advice, not actionable authorization."New value: +"Fallback when preparation.assessmentOutcome is absent and no assessmentId/assessment is bound. Trimmed/truncated to 80 characters. Unknown values are refused. already_satisfied and not_needed_now are refused. insufficient_information cannot issue a claim token unless operatorRequestsExistingFormationAssistance is exactly true on an eligible stored assessment. A caller enum is not a server recommendation. Unbound allowed enum remains provisional advice, not actionable authorization."

addedInput schema / properties / operatorRequestsExistingFormationAssistance

Added value: +{
+  "description": "Optional. Accepted only when exactly true. With a stored assessmentId, an eligible insufficient_information assessment (goal present, no US entity, EIN not already held, no affirmed provider entity or EIN-only requirement) can issue a provisional non-actionable claim. The flag does not affirm a provider requirement, recommend formation, or authorize filing, quote, or payment. String values are refused. Omitted on every other path, including required_for_selected_path.",
+  "type": "boolean"
+}

First observedOct 8, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With readOnlyHint=false and destructiveHint=false already declared, the description still adds real value by naming what is explicitly NOT done (filing, charging, approving, starting checkout) and by stating a human must claim and pay. The only gap is that it does not describe the side effects that actually occur (binding assessment, application, and authority).

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 core behavior and its non-effects are front-loaded in the first two sentences. The third and fourth sentences are dense but each carries a distinct constraint; some redundancy exists between 'does not file, charge, or approve' and 'does not start checkout'.

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?

An output schema exists, so return values need not be explained, and the description correctly covers the human-claim handoff and the non-actionable nature of the tool. Eligibility rules and idempotency details live in the schema, which is acceptable given their depth, though the description alone would not let an agent infer the eligibility conditions.

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 coverage is 71%, below the high-coverage threshold, and the schema itself already documents operationId idempotency, assessmentOutcome refusal cases, and the operator flag in detail. The description reinforces the operator-request/insufficient_information relationship but adds little parameter semantics beyond what the schema says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and resource ('Prepare a provisional application') plus the concrete output ('return the human claim URL'). It is clearly distinguishable from siblings like assess_formation or get_application_status, though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It sets important boundaries ('does not file, charge, or approve', 'does not recommend formation or start checkout') and describes one conditional path tied to insufficient_information plus an operator request. However, it never states when to call this instead of assess_formation or get_application_status, and the conditional path requires schema knowledge to act on.

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

All ein-llc tools Inspect

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

Need Help?