Skip to main content
Glama
Sign In

FactLot

by io.github.9mp96ygnbk-alt
OverviewDiscussionsAdmin

Lease abstract with amendments

doc_abstract_lease
Read-onlyIdempotent

Current-state lease abstract from a lease and its amendments, with amendment precedence, as of as_of. Give each document's pages with the candidates you extracted (checked exactly as doc_verify_facts checks them), or the facts doc_verify_facts already returned for it (without pages only the value against its quote is rechecked, marked quote_on_page: false). Documents may come in any order: give the lease role original and each amendment role amendment with its effective_date (without a role the lease is inferred only when that is unambiguous, otherwise it is an input error; two or more amendments need effective dates). The original applies first, then amendments by effective_date; a later document's value for a predicate controls, and the earlier one moves to history and is linked through supersedes. An amendment effective after as_of is pending: its values are listed under pending and pending_facts with a warning and do not control. A rent schedule restated from a later date keeps the earlier steps before it (carried_forward). Each field gives its value, the controlling document, page, quote and fact, the superseded history, conflicts (two different values from one document, or from two documents of the same rank), pending values and open_items (a candidate for that predicate in the controlling or a later document that needs review or was rejected, so the value may not be final). FactLot only orders what you extracted: it does not find terms you missed, and an amendment that changes a term without restating it ("extended by 24 months") needs the resulting value extracted with that sentence as its quote, which the quote check will hold for review if the date is not written there.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "documents": "<documents>",
      "as_of": "<as_of>"
    },
    "name": "doc_abstract_lease"
  }
}

Input Schema

NameRequiredDescriptionDefault
as_ofYesDate the facts are stated as of (YYYY-MM-DD), usually today.
subjectNoFactLot URN the facts are about, e.g. your lease's fl:lease:… ID. Default: the document ID.
documentsYesThe lease and its amendments. Each needs pages with candidates or facts, or facts alone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / documents / items / properties / candidates / items / properties / commencement
      Added value: +{
+  "description": "Only for lease.base_rent_schedule written by lease year (steps {lease_years: [1, 5], annual_rent_psf}): the commencement date the step dates are derived from, with its own quote. FactLot checks it like a lease.commencement_date candidate and derives each step: Lease Year N runs from the (N−1)th anniversary of the commencement date to the day before the next. If it does not verify, the schedule stays in needs_review.",
+  "properties": {
+    "page": {
+      "description": "1-based page of this document the quote is on (it may differ from the rent table's page).",
+      "maximum": 100000,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "quote": {
+      "description": "Verbatim text that states the commencement date, at least 12 characters.",
+      "maxLength": 5000,
+      "type": "string"
+    },
+    "section": {
+      "description": "Section, if any.",
+      "maxLength": 200,
+      "type": "string"
+    },
+    "value": {
+      "description": "The commencement date (YYYY-MM-DD).",
+      "format": "date",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+      "type": "string"
+    }
+  },
+  "required": [
+    "value",
+    "quote",
+    "page"
+  ],
+  "type": "object"
+}
    • addedInput schema / properties / documents / items / properties / candidates / items / properties / confirmation
      Added value: +{
+  "description": "A person's confirmation of the parts of the value no quote can prove (a true/false value, an enum such as a CAM cap method or kick-out party, a paraphrased summary). With it, a candidate whose only gaps are such parts is verified with method human_verified: the parts the quote confirmed are listed under checked and the rest under confirmed_by_person. It never overrides a quote that is not on the page, a number or date the quote does not state, or a confidence below 0.8.",
+  "properties": {
+    "at": {
+      "anyOf": [
+        {
+          "format": "date",
+          "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+          "type": "string"
+        },
+        {
+          "format": "date-time",
+          "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+          "type": "string"
+        }
+      ],
+      "description": "When the person confirmed it: YYYY-MM-DD, or an ISO 8601 timestamp with offset. A date is recorded on the fact as that day at 00:00 UTC."
+    },
+    "by": {
+      "description": "The name or role of the PERSON who read the clause and confirmed the value, e.g. \"J. Smith, lease administrator\". FactLot does not authenticate it. Never set this for a value no person has read: an agent must not confirm its own extraction.",
+      "maxLength": 200,
+      "minLength": 1,
+      "type": "string"
+    },
+    "note": {
+      "description": "What the person checked; returned with the result (the fact schema has no field for it).",
+      "maxLength": 1000,
+      "type": "string"
+    }
+  },
+  "required": [
+    "by",
+    "at"
+  ],
+  "type": "object"
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / documents / items / properties / effective_date / description
      Previous value: -"Amendment effective date (YYYY-MM-DD). Amendments apply in date order when every amendment has one, otherwise in the order given. Becomes valid_from on its facts."New value: +"Amendment effective date (YYYY-MM-DD), required when there are two or more amendments: they apply in date order, and amendments effective the same day do not supersede each other (a different value is a conflict). An amendment effective after as_of is pending: its values are listed under pending and do not control the current abstract. Becomes valid_from on its facts."
    • changedInput schema / properties / documents / items / properties / role / description
      Previous value: -"Default: \"original\" for the first document, \"amendment\" for the rest."New value: +"Give it. Without one, a document is the original only when no document is marked original and it is the only one without a role (or without a role and an effective_date); otherwise it is an amendment, and input that leaves the original unclear is an error. Input order is never used."
  3. Changed1 schema field changed
    • addedInput schema / properties / documents / items / properties / ocr_pages
      Added value: +{
+  "description": "Optional: pages (1-based) whose text came from OCR rather than the file's text layer (doc_read_pdf and factlot.read_pdf report them). Facts and citations on these pages carry ocr: true, so a reviewer checks the scan.",
+  "items": {
+    "maximum": 100000,
+    "minimum": 1,
+    "type": "integer"
+  },
+  "maxItems": 2000,
+  "type": "array"
+}
  4. Added

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. Beyond that the description adds genuinely new behavioral context: the original applies first, later amendments by effective_date supersede and link through supersedes, amendments effective after as_of are pending and do not control, restated rent schedules keep earlier steps as carried_forward, and open_items/conflicts are surfaced. It also discloses a hard limitation ('FactLot only orders what you extracted: it does not find terms you missed') and that the quote check holds ambiguous quotes for review.

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 purpose is front-loaded in the first clause and virtually every sentence carries operative rules (precedence, pending, conflicts, the extraction limitation). It is dense and written as a long run-on sequence of clauses, which costs readability, but there is little pure filler to cut.

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?

There is no output schema, so the description must describe the return shape, and it does: each field gives value, controlling document, page, quote, fact, superseded history, conflicts, pending values and open_items. For a tool this complex (multi-document precedence resolution plus verification), the description supplies enough to call it correctly and to interpret the result, including the key caveat that the abstract only orders what was extracted.

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

Parameters3/5

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

Schema coverage is 100% and the nested schema descriptions already spell out role inference, effective_date ordering, pending amendments, pages-vs-facts, sha256/document_id derivation, ocr_pages and confirmation semantics. The description restates the same rules at the document level (original first, amendments by date, same-day amendments conflict) but adds little syntax or format detail the schema does not already carry, so the baseline 3 applies.

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 opening clause names a specific verb and resource: 'Current-state lease abstract from a lease and its amendments, with amendment precedence, as of as_of.' It also positions itself against the sibling it depends on (doc_verify_facts), so an agent can distinguish abstracting from mere verification without opening either 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 explains the two input modes clearly (pages+candidates versus facts already returned by doc_verify_facts, with the request-size tradeoff that facts-only yields quote_on_page: false), and states the role/effective_date rules that make input valid. What is missing is an explicit statement of when to reach for this tool rather than doc_verify_facts or doc_compare; the selection is implied by the phrase 'current-state abstract ... with amendment precedence' rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All FactLot toolsInspect
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.

Resources