Lovie Company Formation

Import SAFE

cap_table_import_safe

Destructive

Imports a SAFE from an uploaded SAFE PDF and stores the document in S3. USE THIS (not RecordCapTableInvestment) whenever the user provides or uploads a SAFE PDF file. Flow: (1) call GetOcrUploadUrl with kind=SAFE and mime_type=application/pdf to get a presigned PUT URL + source_s3_uri, (2) upload the PDF bytes to that PUT URL, (3) call ImportSAFE with that source_s3_uri. This runs OCR to extract the terms; pass valuation_cap / investment_amount / discount_rate only to CORRECT a value the user says the OCR misread, and leave them empty to keep what the document says. Call ExtractSafeTerms first and get the user's confirmation before importing. effective_date is required — never import a SAFE without a date. If the company named on the document differs from this company, say both names and get the user's confirmation before importing. It copies the PDF to the canonical cap-table SAFE location, links it to a SAFE agreement, resolves the investor by name (matching an existing stakeholder or creating a new one), and creates the security. The security is marked signed only if the document is actually signed; an unsigned SAFE PDF is still stored and left committed. Whenever the user has the PDF — including when they attached it to this conversation — upload it and pass source_s3_uri so the document itself is stored; a SAFE created from typed terms alone has nothing on record proving its date or signature, and the cap table flags it as missing its document. Use RecordCapTableInvestment only for a SAFE the user genuinely has no document for. The response carries the cap table before this call, what it added, and the cap table after — report an import in exactly that order (current table, new additions, final table) and take the totals from the response rather than reading the cap table again. For several SAFEs at once, list every one you are about to add and get a yes before the first call, not after the last.

Input Schema

TableJSON Schema

Name	Required	Description
`preview`	No
`roundId`	No	UUID value wrapper.
`companyId`	Yes	UUID value wrapper.
`postMoney`	No
`documentId`	No	UUID value wrapper.
`sourceS3Uri`	No
`discountRate`	No
`valuationCap`	No
`effectiveDate`	No
`stakeholderId`	No	UUID value wrapper.
`consentToAiRead`	No
`investmentAmount`	No
`newStakeholderName`	No

Output Schema

TableJSON Schema

Name	Required	Description
`change`	No
`status`	No
`created`	No
`preview`	No
`securityId`	No	UUID value wrapper.
`agreementId`	No	UUID value wrapper.
`stakeholderId`	No	UUID value wrapper.
`consentVersion`	No
`consentBodyMarkdown`	No

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only indicate destructiveHint=true and openWorldHint=false. The description adds extensive behavioral context: the S3 upload flow, OCR term extraction, correction behavior, effective_date requirement, handling of company name mismatches, signed/unsigned SAFE handling, investor resolution, and response ordering. This goes well beyond the annotations without contradicting them.

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 well-structured: it starts with the core action, then provides the multi-step flow, usage rules, edge cases, and response-handling instructions. Every sentence adds value, though a few could be tighter. It is not overly verbose given the tool's complexity.

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 tool has 13 parameters, an output schema, and destructive behavior, the description thoroughly covers the complete workflow: prerequisites (GetOcrUploadUrl), upload steps, alternative tool usage, required fields, handling of mismatched companies, unsigned documents, and multi-SAFE batching. It even over-delivers by explaining how to report results, which is not required from an output schema.

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?

Schema description coverage is only 31%, so the description carries a heavy burden. It adds meaning to core parameters: valuation_cap/investment_amount/discount_rate are for correcting OCR misreads, effective_date is required, sourceS3Uri is the uploaded PDF path. However, it doesn't explicitly explain all 13 parameters (e.g., preview, postMoney, consentToAiRead), leaving some gaps.

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 specific verb and resource: 'Imports a SAFE from an uploaded SAFE PDF and stores the document in S3.' It clearly distinguishes this tool from RecordCapTableInvestment and ExtractSafeTerms by naming them and stating when to use each, making the purpose unambiguous.

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?

Provides explicit usage guidance: 'USE THIS (not RecordCapTableInvestment) whenever the user provides or uploads a SAFE PDF file' and 'Use RecordCapTableInvestment only for a SAFE the user genuinely has no document for.' Also instructs to call ExtractSafeTerms first and get user confirmation, defining the workflow and exclusions.

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

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.

Import SAFE

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources