Skip to main content
Glama

Lovie Company Formation

by co.lovie

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 and ignore billing_interval (it is deprecated and has no effect). 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
NameRequiredDescriptionDefault
attributionNo
formationIdYesUUID value wrapper.
billingIntervalNo
subscriptionOnlyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
lineItemsNo
paymentUrlNo
totalCentsNo
formationIdNoUUID value wrapper.
totalDisplayNo
paymentStatusNo
filingFeeCentsNo
billingIntervalNo
filingFeeDisplayNo

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only indicate openWorldHint and destructiveHint false, so the description carries the full burden. It explicitly states that calling the tool files nothing and charges nothing, that it may trigger a native sign-in prompt, and that it does not confirm payment. This is rich, accurate behavioral disclosure far 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.

Conciseness5/5

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

Although long, the description is front-loaded and every sentence carries critical operational guidance (safety, login, one-time payment, URL handling, no duplicate calls). The verbosity is justified given the tool's complexity and the consequences of misuse.

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?

With an output schema present, the description doesn't need to list return fields, but it still mentions the returned URL and filing_fee_display. It covers safety, sign-in behavior, one-time payment semantics, URL manipulation rules, and post-payment expectations, making it exceptionally complete.

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

Parameters4/5

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

The schema has 4 parameters but only formationId has a description (25% coverage). The description compensates by explaining that billing_interval is deprecated and has no effect, and that there is no subscription, implying billingInterval and subscriptionOnly are irrelevant. However, it does not explain the attribution parameter, leaving a minor 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 clearly states the tool's purpose: generating a single Stripe Checkout URL for the entire formation purchase. It distinguishes itself from siblings by explicitly noting it is not a login tool, not a separate filing-fee checkout, and covers the whole purchase in one one-time payment.

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 provides extensive when-to-use and when-not-to-use guidance: it is also the sign-in step, there is no separate login tool, do not call more than once, do not create a separate filing-fee checkout, and ignore the deprecated billing_interval. This makes the tool's usage unmistakable.

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 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.5/5.0
Disambiguation1/5

Multiple tool pairs are nearly identical (formation_extract_cap_table / formation_extract_cap_table_ocr; formation_start_formation / formation_create_formation), and several tools lack descriptions, making selection ambiguous. The scale of 202 tools with overlapping summaries (e.g., multiple cap-table summary tools) compounds the confusion.

Naming Consistency3/5

Dominant snake_case `module_verb_noun` pattern, but with notable deviations: `captable_send_safe_for_signature` uses an inconsistent abbreviation, `check_company_name_availability` lacks a module prefix, and `get_list_` vs `list_` prefixes are mixed. Readable but not fully consistent.

Tool Count1/5

202 tools is far beyond any reasonable surface for a single server, even a broad platform. The sheer number overwhelms and makes tool discovery impractical; many tools are peripheral (ads metrics) to the core formation purpose.

Completeness4/5

The domain appears well covered: formation flows, cap-table lifecycle (import, close, simulate), accounting (journal entries, periods, schedules), cards, documents, and transactions all have CRUD or lifecycle operations. Minor gaps exist (e.g., no card deletion, no counterparty creation), but they are unlikely to cause dead ends.

Resources