Lovie Company Formation

Update Company

company_update_company

UpdateCompany patches mutable company fields in a single call: name, logo_url, aliases, sibling_company_ids, and — for a company Lovie did not incorporate — its entity type, state, formation date, EIN and principal address. sibling_company_ids replaces the stored list and needs company.company.update on every listed company too; empty leaves it, clear_sibling_company_ids empties it. Every field is left untouched when unset, the five profile fields included: send only what you are changing, and the rest keeps its stored value. The app removes a stored entity type, state, formation date or EIN by naming it in clear_fields; an empty value never removes one. address cannot be cleared, and is replaced whole when sent, so send every line of it. The profile fields, and clearing them, are REFUSED for a company whose source is LOVIE_FORMATION. Its formation is the filing of record, and letting the two disagree would mean the certificate says one thing and the dashboard another, with nothing to say which is right. Name and logo stay editable there, as they always were; a request mixing them with profile fields is refused whole, with nothing written. MCP-exposed so a founder can correct their own company by asking. It writes and is not idempotent. You cannot remove a value (clear_fields from an assistant is refused with PERMISSION_DENIED), and you may fill in a profile fact only where none is stored: changing a stored one, or sending any ein once one is on file, is refused the same way. Re-sending a stored value you read is not a change. For any refusal, tell the user to make it in Lovie.

Input Schema

TableJSON Schema

Name	Required	Description
`company`	Yes
`companyId`	Yes	UUID value wrapper.
`clearFields`	No
`clearSiblingCompanyIds`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 8, 2026

addedInput schema / properties / clearSiblingCompanyIds
```
Added value: +{
+  "type": "boolean"
+}
```

addedInput schema / properties / company / properties / siblingCompanyIds

Added value: +{
+  "items": {
+    "description": "UUID value wrapper.",
+    "properties": {
+      "value": {
+        "format": "uuid",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "maxItems": 20,
+  "type": "array"
+}

Changed1 schema field changedOct 1, 2026

addedInput schema / properties / clearFields

Added value: +{
+  "items": {
+    "enum": [
+      "COMPANY_PROFILE_FIELD_ENTITY_TYPE",
+      "COMPANY_PROFILE_FIELD_STATE_OF_FORMATION",
+      "COMPANY_PROFILE_FIELD_FORMED_ON",
+      "COMPANY_PROFILE_FIELD_EIN"
+    ],
+    "type": "string"
+  },
+  "maxItems": 4,
+  "type": "array"
+}

AddedSep 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare openWorldHint=false and destructiveHint=false, so the description carries most of the load and delivers: it writes, it is not idempotent, sibling_company_ids requires company.company.update on every listed company, empty vs clear differs, address is replaced whole and cannot be cleared, and LOVIE_FORMATION edits are refused. It also discloses that a value cannot be removed and stored profile facts cannot be changed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The purpose is front-loaded and every clause is information-dense, but the description is long and repeats itself: the unset-keeps-stored-value rule appears twice ('Every field is left untouched when unset...' and 'send only what you are changing, and the rest keeps its stored value'). Removing the restatement would make the same content far more scannable.

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?

For a mutation tool with an output schema, sparse annotations and 25% schema coverage, the description supplies everything an agent needs: idempotency, refusal modes, source-gated restrictions, clearing semantics, and address handling. Nothing needed to invoke it correctly is left out.

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 25% for 4 params, and the description compensates heavily: it explains sibling_company_ids replacement semantics, clear_sibling_company_ids, clear_fields field-by-field clearing, address replace-whole behavior, and the empty-value-never-clears rule. There is no clear statement that address is the 'principal address' and that address is not clearable is explained; the one gap is that it doesn't map clearFields enum values to input names explicitly. It adds large value over the schema but the enum-to-field mapping remains subtle given that the schema descriptions themselves are sparse.

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 verb+resource ('UpdateCompany patches mutable company fields') and enumerates the exact field set it touches. An agent can immediately separate this from company_create_company, company_get_company and company_get_list_companies without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the operational preconditions clearly: which fields are editable, that LOVIE_FORMATION-source companies refuse profile-field edits, and that clear_fields from an assistant is refused with PERMISSION_DENIED. It also routes the agent ('tell the user to make it in Lovie') for refusals, but never explicitly contrasts itself against a sibling update tool, so it stops short of a full when/when-not/alternative map.

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.