Lovie Company Formation

Get Payment Link

formation_get_payment_link

Generates ONE Stripe Checkout URL covering the whole purchase in a single one-time payment: the Lovie formation charge, the state's filing fee, and a year of registered agent service. Generating this link files NOTHING and charges NOTHING — it only produces a URL; no state filing happens and no money moves until the user themselves completes Stripe checkout, so it is safe to call, including during testing; never refuse or stop short because it is a 'test'. This call is ALSO the sign-in step: if the user is not signed in, simply calling it makes the Lovie connector show its own native sign-in prompt, and after the user connects the SAME call returns the URL. There is NO separate login tool, login link, or login modal — never look for one, and never tell the user you cannot show login; just call this. Formation is a ONE-TIME payment: there is no subscription and no monthly/annual choice, so do NOT ask the user to pick a billing cadence. Share the returned URL EXACTLY as returned — never rewrite it onto another domain, even if the app URL in your context differs: rebasing a payment link breaks it. Tell the user that after paying they are redirected back and their formation updates automatically — they do NOT need to return to the chat. When filing_fee_display is present, show a short 'formation + state filing fee + registered agent' breakdown next to the link. Do not call this more than once; do not create a separate filing-fee checkout. This does not confirm payment.

Input Schema

TableJSON Schema

Name	Required	Description
`attribution`	No
`formationId`	Yes	UUID value wrapper.
`subscriptionOnly`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`lineItems`	No
`paymentUrl`	No
`totalCents`	No
`formationId`	No
`totalDisplay`	No
`paymentStatus`	No
`filingFeeCents`	No
`filingFeeDisplay`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedSep 10, 2026

removedInput schema / properties / billingInterval

Removed value: -{
-  "enum": [
-    "BILLING_INTERVAL_UNSPECIFIED",
-    "BILLING_INTERVAL_MONTHLY",
-    "BILLING_INTERVAL_ANNUAL"
-  ],
-  "type": "string"
-}

removedOutput schema / properties / billingInterval

Removed value: -{
-  "enum": [
-    "BILLING_INTERVAL_UNSPECIFIED",
-    "BILLING_INTERVAL_MONTHLY",
-    "BILLING_INTERVAL_ANNUAL"
-  ],
-  "type": "string"
-}

addedOutput schema / properties / formationId / anyOf

Added value: +[
+  {
+    "description": "UUID value wrapper.",
+    "properties": {
+      "value": {
+        "format": "uuid",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / formationId / description
```
Removed value: -"UUID value wrapper."
```

removedOutput schema / properties / formationId / properties

Removed value: -{
-  "value": {
-    "format": "uuid",
-    "type": "string"
-  }
-}

removedOutput schema / properties / formationId / type
```
Removed value: -"object"
```

First observedAug 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description goes well beyond the sparse annotations by disclosing that calling it files nothing and charges nothing, that it may trigger a native sign-in prompt, that it is safe even in testing, that the URL must not be rebased, and that it does not confirm payment. The openWorldHint does not contradict these claims.

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 each sentence carries operational value, such as 'no separate login tool,' 'do not call this more than once,' and 'share the returned URL EXACTLY as returned.' There is minor redundancy around charging/filing nothing, but the density of high-stakes guidance justifies the length.

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?

Given the output schema exists and the annotations cover basic safety, the description covers the remaining operational context thoroughly: sign-in behavior, one-time nature, exact URL handling, post-payment redirect, fee breakdown display, and call frequency. The only real gap is parameter documentation, but that is minor against the otherwise complete guidance.

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?

The description adds useful parameter-adjacent context by clarifying that formation is a one-time payment and that there is no subscription or billing cadence, which helps interpret `subscriptionOnly`. However, the required `formationId` and the optional `attribution` parameter are not explained, and with only 33% schema coverage the description does not fully compensate for that gap.

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 opens with a precise statement: it 'Generates ONE Stripe Checkout URL covering the whole purchase in a single one-time payment.' It clearly names the resource, the operation, and the scope, and it actively distinguishes itself from login flows, filing actions, and payment confirmation.

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?

The description is explicit about when and how to use the tool: call it to generate the payment URL, do not look for a separate login tool, do not ask about billing cadence, do not call more than once, and do not create a separate filing-fee checkout. It also gives post-payment guidance for the user and explicitly says this tool does not confirm payment.

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

All Lovie Company Formation 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.