Skip to main content
Glama

Get a registry record

registry_get
Read-onlyIdempotent

Everything the FactLot Registry knows about a parcel, legal entity, or building: status, current cited facts (owner of record, situs address, property category, areas, values), ownership links, external IDs, and for a parcel the building it belongs to (condominium units roll up into one building). value_history (parcels) lists market and appraised value by tax year from every snapshot, newest first, each value cited; a tax year two snapshots value differently appears once per value. as_of gives the facts as they stood on a date. warnings flags area facts that look wrong (building area above 40 times the land area, a land area of 0); the facts themselves are as the source publishes them. A building record can carry debt.cmbs_loan facts (one per CMBS trust holding a note of its loan: balance, rate, maturity, payment status, servicer, special-servicing dates, NOI, DSCR) and an entity record can carry entity.parent facts (the SEC registrant that lists it as a subsidiary in Exhibit 21), each cited to its SEC filing. A miss says whether the county or entity registry is loaded. Requires a FactLot Registry (public-record facts about commercial property, each cited to the source file and record).

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": {
      "urn": "<urn>"
    },
    "name": "registry_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
urnYesFactLot URN of a parcel, entity, or building, e.g. fl:parcel:us-48201:0011440000001.
as_ofNoDate (YYYY-MM-DD): return the facts and ownership links current on that date, from the snapshots dated on or before it, instead of the latest. With include_history, history stops at that date.
include_historyNoAlso return every fact from every snapshot, superseded ones included (history lists current facts too; a source loaded once has no superseded facts).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / urn / description
      Previous value: -"FactLot URN of a parcel, entity, or building, e.g. fl:parcel:us-48201:0420150000012."New value: +"FactLot URN of a parcel, entity, or building, e.g. fl:parcel:us-48201:0011440000001."
  2. Added

TDQS

A4/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, the description explains snapshot behavior via as_of, how value_history handles repeated tax-year values, what warnings flags, that source-published facts are not corrected, and what happens on a miss. It also identifies the registry prerequisite, which is useful operational context.

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 opening sentence is front-loaded and the description contains no obvious filler; the density is justified because there is no output schema to explain the rich return payload. The main weakness is structure: a long single paragraph with field catalogs and edge cases is harder to scan than it could be.

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 high-complexity record-retrieval tool with no output schema, the description is complete enough: it explains the returned record types, history and as_of semantics, value_history ordering, warnings, CMBS and entity-parent facts, and miss behavior. An agent has enough information to invoke it correctly and interpret the main response shape.

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 description coverage is 100%, so the schema already fully documents urn, as_of, and include_history. The description reinforces as_of behavior and history semantics, but it does not add parameter-level detail beyond what the schema already provides, especially for include_history.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly establishes that this retrieves everything the FactLot Registry knows about a parcel, entity, or building, which is a specific resource. It does not explicitly name sibling tools like registry_resolve_parcel or registry_search_address, so the differentiation is implied by scope rather than stated.

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

Usage Guidelines3/5

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

The description implies usage by stating it requires a FactLot Registry and explaining that a miss reports whether the county or entity registry is loaded. However, it gives no explicit guidance on when to use this versus the search/resolve siblings, nor does it say the caller should already possess a FactLot URN.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.