Lovie Company Formation

Reconcile Document Signature State

signature_reconcile_document_state

DestructiveIdempotent

ReconcileDocumentSignatureState re-runs the document-hub write-back for every envelope that is not voided, so the hub carries the signature state of envelopes created before the write-back understood subjects that name a record rather than a document. Platform-wide, never scoped to the caller's company: it reads and rewrites the signature pointer on every tenant's document rows. Invoked on demand, not on a cron. Its purpose is a backfill — the surfaces that read the hub would otherwise report every pre-existing SAFE as unsent — and it stays available afterwards because the same repair is needed whenever a write-back was lost (the document service unreachable at signing time, say). Reports by default; set apply to write. The safe mode is the zero value deliberately — see the field's own comment. Idempotent in effect, not in cost: the write is an upsert of (signature_envelope_id, signed_at) on the hub row, so repeating it converges rather than accumulating, but every call sweeps the whole platform. One case is NOT idempotent, and it is why this runs on demand rather than on a cron. The sweep resolves every envelope before it writes any row, and resolving costs one RPC per envelope over as many as 5000 of them, so the gap between reading an envelope and writing its row can span the whole run. A signature that completes inside that gap is overwritten by the winner the sweep decided on earlier. The write is unconditional anyway because the rows this backfill exists for carry no envelope at all, and a compare-and-set against an expected id cannot match an empty row. Run it when signing is quiet, and re-run it afterwards if it is not.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`apply`	No
`resumeToken`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`errors`	No
`skipped`	No
`written`	No
`complete`	No
`examined`	No
`errorsOmitted`	No
`nextResumeToken`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 10, 2026

TDQS

B3.3/5.0

Behavior1/5

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

The description contradicts the idempotentHint annotation: it states 'Idempotent in effect, not in cost' but then says 'One case is NOT idempotent' due to a race that can overwrite a signature completed during the sweep. This directly conflicts with the annotation 'idempotentHint: true', and the rule mandates a score of 1 for annotation contradictions.

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 every sentence adds meaningful detail: purpose, scope, invocation mode, idempotency caveat, race condition explanation, and operational guidance. It is front-loaded with the core purpose and stays relevant, but it could be more structured/compact (e.g., splitting the race explanation into its own clearly-labeled section).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description thoroughly covers purpose, scope, interaction model, cost, timing, and the non-idempotent edge case, and an output schema exists. However, it omits any explanation of resumeToken, which is a real parameter, and relies on a missing 'field's own comment' to clarify the zero-value default. This leaves a meaningful gap for agents trying to correctly invoke the tool.

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?

Schema description coverage is 0%, so the description must explain the parameters. It partially explains 'apply' ('Reports by default; set apply to write') but does not describe 'resumeToken' at all, and it references a field comment that is not visible. An agent would not know how to use resumeToken or its semantics, so the description does not sufficiently compensate for the schema 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 uses a specific verb ('re-runs the document-hub write-back') and identifies the exact resource and scope (every non-voided envelope, platform-wide). It clearly distinguishes this from ordinary signature tools by emphasizing the backfill/repair nature and the 'never scoped to the caller's company' platform-wide behavior.

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?

The description explicitly says this is invoked on demand, not on a cron, and provides concrete timing guidance ('Run it when signing is quiet, and re-run it afterwards if it is not'). It also explains the apply/report mode. However, it does not name alternative sibling tools or exclusions, though no sibling appears to overlap directly.

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.