Skip to main content
Glama

Lovie Company Formation

by co.lovie

Extract RSA Terms OCR

formation_extract_rsa_terms_ocr

Runs vision OCR on an already-uploaded signed Restricted Stock Purchase/Award Agreement (RSA) PDF for the active company and returns the founder and company names plus structured terms (total_shares, unvested_shares, price_per_share, grant_date, vesting_start_date / vesting_total_months / vesting_cliff_months, acceleration_clause, repurchase_right, 83(b) status, etc.) WITHOUT persisting anything. Empty string / 0 / false means the value was not stated in the document — never fabricate. Flow: first call GetOcrUploadURL with kind=RSA and upload the PDF, then call this tool with the returned source_s3_uri. To persist the grant and link the document, pass the extracted terms and the SAME source_s3_uri to CreateCapTableAgreement with type=CAP_TABLE_AGREEMENT_TYPE_RSA — preserve the vesting fields, do not drop them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agentCodeNo
companyIdYesUUID value wrapper.
sourceS3UriNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rsaTermsNo
warningsNo
companyNameNo
founderNameNo
sourceS3UriNo
ocrConfidenceNo

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only set openWorldHint=false and destructiveHint=false. The description adds crucial behavioral truths: 'WITHOUT persisting anything' (read-only nature) and 'never fabricate' semantics for empty values. This goes well beyond the sparse 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?

The description is dense but each element earns its place: purpose, non-persistence, missing-value semantics, and the workflow. It is front-loaded with the main action, though the long field list and flow instructions make it slightly verbose.

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?

With an output schema present, not listing every return field is fine. The description gives the essential workflow and post-conditions. Minor gaps: sourceS3Uri is not required in the schema but implied necessary, and agentCode is unaddressed. Overall, complete enough for safe usage.

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 coverage is low (33%) with only companyId described as a UUID wrapper. The description explains source_s3_uri origin (from GetOcrUploadURL) and companyId as 'active company', adding value. However, agentCode is never mentioned, leaving a semantic 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 specific action ('Runs vision OCR'), the target resource ('signed Restricted Stock Purchase/Award Agreement (RSA) PDF'), and the output (founder/company names plus structured vesting terms). It explicitly mentions non-persistence, distinguishing it from similar tools like formation_extract_cap_table_ocr or formation_extract_safe_terms.

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 an explicit flow: call GetOcrUploadURL first, then this tool with the returned source_s3_uri, and optionally persist via CreateCapTableAgreement. It names the exact sibling tools and states the context (after upload, before persistence), giving clear when-to-use guidance.

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