FactLot

Tie out CAM reconciliations against another system's results

calc_reconcile_cam

Read-onlyIdempotent

Reconcile FactLot's CAM reconciliation for one expense pool with another system's per-tenant results (Yardi or any other; parity is not claimed and is untested against a real export): give the calc_cam_reconciliation_batch input plus, per tenant, what the other system reported (share, gross-up, cap limit and reduction, admin fee, base-year or stop deduction, billed amount, estimates, balance; billed_amount required) and a tolerance. Returns per tenant and line FactLot's amount, the other amount, the difference and whether it is within tolerance, tenants missing on either side, and likely causes worded as hypotheses to check: a different pro rata share (and, when every share differs by one factor, the pool's denominator), or a FactLot rerun that matches the other system with lines left to the default controllable: true set uncontrollable, the cap's base year one year off, the other cap method, the other gross-up target or no gross-up, the admin fee before or after and within or outside the cap, or no fee on uncontrollable lines; and differing estimates paid. Deterministic: use this instead of doing the math yourself; cite formula calc.reconcile_cam@1 and the returned steps, and surface any warnings.

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": {
      "cam": "<cam>",
      "other": "<other>"
    },
    "name": "calc_reconcile_cam"
  }
}

Input Schema

Name	Required	Description
`cam`	Yes	The FactLot CAM input for one expense pool, exactly as calc_cam_reconciliation_batch takes it (the same pool, shares and lease terms you entered in the other system).
`other`	Yes	What the other system reported for the same pool and year.
`tolerance`	No	When two amounts agree: \|FactLot − other\| ≤ max(absolute, relative × \|other\|); shares within share. Default: 1.00 USD, 0, and 0.000001.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 7, 2026

changedInput schema / properties / cam / properties / expenses / items / properties / controllable / description

Previous value: -"Subject to the cap. Taxes, insurance, and utilities are typically uncontrollable."New value: +"Subject to the cap. Taxes, insurance, and utilities are typically uncontrollable. Default true; under a cap, lines left unset are named in warnings."

changedInput schema / properties / cam / properties / expenses / items / properties / variable / description

Previous value: -"Varies with occupancy, so eligible for gross-up (janitorial, utilities, management fee)."New value: +"Varies with occupancy, so eligible for gross-up (janitorial, utilities, management fee). Default false; with a gross-up, lines left unset are named in warnings."

AddedNov 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well past the readOnly/idempotent annotations: it discloses what is returned (per-tenant and per-line amounts, differences, tolerance status, tenants missing on either side), names the diagnostic hypotheses it will raise, warns that causes are 'hypotheses to check' rather than findings, commits to determinism, and requires citing calc.reconcile_cam@1 and surfacing warnings. The untested-parity disclaimer is exactly the kind of risk context annotations cannot express.

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?

Purpose is front-loaded, but the body is a single semicolon-chained sentence of roughly 200 words mixing input requirements, return values, diagnostic hypotheses, and citation rules. Every clause carries information, yet the lack of sentence breaks or list structure makes it hard to scan for an agent consuming it in one pass.

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 no output schema and a deeply nested input, the description supplies the missing return-shape context (per-tenant and per-line comparison, missing tenants, hypotheses, warnings) and the determinism/citation contract. It does not pin down exact output field names, but nothing needed to invoke the tool correctly is absent.

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 100%, so the baseline is 3, but the description adds selection guidance over the schema: it enumerates which 'other' fields are worth supplying (share, gross-up, cap limit and reduction, admin fee, base-year/stop deduction, billed amount, estimates, balance) and flags that billed_amount alone is required. It does not clarify the tolerance semantics beyond what the schema already documents.

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?

States a specific verb and resource — 'Reconcile FactLot's CAM reconciliation for one expense pool with another system's per-tenant results' — and explicitly scopes it to a single pool, which separates it from calc_cam_reconciliation and calc_cam_reconciliation_batch. An agent can identify the tool 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?

Tells the agent to feed it 'the calc_cam_reconciliation_batch input' plus the other system's figures, and explicitly says 'use this instead of doing the math yourself,' which routes correctly against manual math and against the pure-calc siblings. It lacks an explicit 'do not use when' clause, and the caveat that parity is 'not claimed and is untested against a real export' is stated but not turned into a usage condition.

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

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