Skip to main content
Glama
Sign In

FilingDesk Data

by com.filingdesk
OverviewDiscussionsAdmin

Preview a formation order

preview_order
Read-only

Validates and prices a formation order and returns the exact summary that would be submitted, WITHOUT submitting anything (no side effects). Use when the user wants FilingDesk to form their LLC or corporation and has provided the business name, state, entity type, and their name, email, and phone. The returned summary is meant to be shown to the user verbatim, and this step is required before submit_order.

Input Schema

NameRequiredDescriptionDefault
emailYesThe customer's email. Required — this is where documents go. Temporary/disposable inboxes are rejected.
phoneYesThe customer's phone number with area code. Required — used only if the state or the specialist has a question about the filing.
stateYesTwo-letter state code or full state name, e.g. "WY" or "Wyoming". All 50 states + DC.
fullNameYesThe customer's full name.
entityTypeYesEntity type, e.g. "LLC", "S-Corp", "C-Corp", or "Not sure" if the user hasn't decided.
descriptionNoOne or two sentences on what the business does. Optional — the user may skip it.
businessNameYesProposed company name. Does not need to be final — a specialist verifies availability.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / email / description
      Previous value: -"The customer's email. Required — this is how they are contacted."New value: +"The customer's email. Required — this is where documents go. Temporary/disposable inboxes are rejected."
    • changedInput schema / properties / phone / description
      Previous value: -"Optional phone number."New value: +"The customer's phone number with area code. Required — used only if the state or the specialist has a question about the filing."
    • changedInput schema / required
      Previous value: -[
-  "businessName",
-  "state",
-  "entityType",
-  "fullName",
-  "email"
-]New value: +[
+  "businessName",
+  "state",
+  "entityType",
+  "fullName",
+  "email",
+  "phone"
+]
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them while adding genuine context: no side effects, the returned summary is meant to be shown to the user verbatim, and it is a mandatory precursor to submit_order. It does not cover failure modes or validation-rejection behavior, which keeps it short of a 5.

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

Conciseness5/5

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

Two sentences, both front-loaded: the core action and its no-side-effect guarantee come first, followed by the usage condition and the sequencing requirement. No filler or restated title.

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?

Although no output schema exists, the description explains what comes back ('the exact summary that would be submitted') and how to handle it (show verbatim), plus the required precondition. For a 7-param read-only tool, this leaves nothing important unstated.

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 100%, so each parameter already carries its own guidance (all 50 states + DC, disposable-inbox rejection, etc.). The description only recaps which fields the user must provide, adding no syntax or format detail beyond the schema, so baseline 3 applies.

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 gives a specific verb pair and resource ('validates and prices a formation order') and states the key scope constraint ('WITHOUT submitting anything'). It is immediately distinguishable from the sibling submit_order, which it names explicitly.

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 states exactly when to use it (user wants to form an LLC/corp and has supplied name, state, entity type, and contact info) and where it sits relative to the alternative: 'this step is required before submit_order.' The no-side-effects framing also signals when to prefer this over the real submission.

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

All FilingDesk Data 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