Skip to main content
Glama

Lovie Company Formation

Get Payment Link

formation_get_payment_link

Generates ONE Stripe Checkout URL for the whole purchase in a single one-time payment. Formation is ONE flat all-inclusive price, the same in every state, and it covers the state's filing fee, a year of registered agent service, the EIN application, five scanned mailpieces a year and one domain. Never quote the amount from memory — call formation_get_formation_quote, which also returns the inclusion list to read back. 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. Show the total and the includes list beside the link, so the buyer can see the state fee and the registered agent are already in it. There is no second payment of any kind — no separate filing fee, no add-on to tick. Do not call this more than once. This does not confirm payment.

Input Schema

NameRequiredDescriptionDefault
attributionNo
formationIdYesUUID value wrapper.

Output Schema

NameRequiredDescriptionDefault
includesNo
lineItemsNo
paymentUrlNo
totalCentsNo
formationIdNo
totalDisplayNo
paymentStatusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • removedInput schema / properties / subscriptionOnly
      Removed value: -{
      -  "type": "boolean"
      -}
    • removedOutput schema / properties / filingFeeCents
      Removed value: -{
      -  "type": "string"
      -}
    • removedOutput schema / properties / filingFeeDisplay
      Removed value: -{
      -  "type": "string"
      -}
    • addedOutput schema / properties / includes
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Changed6 schema fields changed
    • 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"
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare openWorldHint and destructiveHint=false, but the description adds substantial behavior: generating the link files and charges nothing, money moves only after the user completes Stripe checkout, the call doubles as the sign-in step via a native connector prompt, and the returned URL must not be rebased onto another domain. This is exactly the extra context annotations cannot carry.

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 purpose is front-loaded and most sentences target a distinct failure mode (rebasing, double-calling, asking for billing cadence), which earns their place. There is some redundancy in restating the one-time/no-second-payment point, keeping it from a perfect score, but it remains well organized.

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?

An output schema exists, so the description need not document the returned URL or includes list. It covers the safety profile, the auth/sign-in behavior, the caller's obligations (show total beside the link, redirect expectation, exact URL sharing), which is complete for what the agent must do.

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

Parameters2/5

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

With schema coverage at only 50% and two parameters, the description carries the burden of compensation but says nothing about formationId or the attribution map. The schema itself labels formationId only as a 'UUID value wrapper', so neither source explains how to supply the formation identity or what attribution does.

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?

States a specific verb and resource: generates ONE Stripe Checkout URL for the whole purchase as a single one-time payment. It also distinguishes itself from the sibling that supplies the amount (formation_get_formation_quote), so the agent can route between them without opening schemas.

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?

Explicit when-to-use and when-not guidance: call this to produce the link, never quote the amount from memory but call formation_get_formation_quote instead, do not call more than once, and it is safe to call during testing. It also names the alternative for pricing and forbids hunting for a nonexistent login tool, leaving nothing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.