Arc & Ledger Tax Tools

Compare US formation states

compare_formation_states

Read-only

Use this when someone (often a non-US founder) asks which US state to form their LLC or company in - Wyoming, New Mexico, Delaware, or California. Compares government fees, annual cost, franchise tax, privacy, and approval time, and recommends a state based on their situation.

Input Schema

TableJSON Schema

Name	Required	Description
`priority`	No	What matters most: lowest_cost, most_privacy, or investor_ready. Defaults to lowest_cost.
`operates_in_california`	No	Whether you (or the business) physically operate in, or are a resident of, California. If true, California registration is generally required regardless of where you form.
`raising_venture_capital`	No	Whether you plan to raise venture capital or convert to a C-corp. If true, Delaware is usually preferred by investors.

Output Schema

TableJSON Schema

Name	Required	Description
`relay`	Yes	Instruction to the calling assistant: relay figures and dates verbatim (identical on every response).
`next_step`	Yes	A single review link appropriate to this server surface.
`disclaimer`	Yes	General-information disclaimer (identical on every response).
`source_url`	Yes	The arcandledger.com page that backs this answer.
`server_version`	No	Server release that produced this response (matches GET /version).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedJul 26, 2026

changedOutput schema / properties / next_step / description

Previous value: -"A single human handoff to the firm."New value: +"A single review link appropriate to this server surface."

Changed2 schema fields changedJul 13, 2026

addedOutput schema / properties / relay

Added value: +{
+  "description": "Instruction to the calling assistant: relay figures and dates verbatim (identical on every response).",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "disclaimer",
-  "source_url",
-  "next_step"
-]New value: +[
+  "disclaimer",
+  "relay",
+  "source_url",
+  "next_step"
+]

Changed1 schema field changedJul 12, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "disclaimer": {
+      "description": "General-information disclaimer (identical on every response).",
+      "type": "string"
+    },
+    "next_step": {
+      "description": "A single human handoff to the firm.",
+      "properties": {
+        "label": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "label",
+        "url"
+      ],
+      "type": "object"
+    },
+    "server_version": {
+      "description": "Server release that produced this response (matches GET /version).",
+      "type": "string"
+    },
+    "source_url": {
+      "description": "The arcandledger.com page that backs this answer.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "disclaimer",
+    "source_url",
+    "next_step"
+  ],
+  "type": "object"
+}

First observedJul 8, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's claim of comparing and recommending is consistent and adds context (states and factors) but not further behavioral details beyond the 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?

Two sentences, no wasted words. Efficiently conveys when to use, what it compares, and what it outputs. Could be slightly more structured but remains highly concise.

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?

Given the tool has no required parameters and an output schema (implied), the description covers the essential context: target user, states compared, comparison factors, and recommendation output. It sufficiently prepares an agent for correct usage.

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 has 100% description coverage; each parameter's schema description is detailed. The tool description adds high-level context but does not provide additional parameter-specific meaning beyond what the schema offers.

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?

Description clearly states the tool compares US states for LLC/company formation, lists specific states (Wyoming, New Mexico, Delaware, California), and mentions factors compared (fees, cost, tax, privacy, approval time). It distinguishes from sibling compare_llc_scorp which compares entity types.

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

Usage Guidelines4/5

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

Description explicitly tells when to use this tool: 'when someone asks which US state to form their LLC or company in'. While it doesn't mention when not to use or list alternatives, the context and sibling tool names provide enough differentiation.

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

All Arc & Ledger Tax Tools 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.