Skip to main content
Glama

West Kite: US commercial property owners & records

Query West Kite's records

query
Read-onlyIdempotent

Read-only SQL over West Kite's records for counts, group-bys, rankings, distance screens and criteria across sales, loans and businesses. One SELECT over the views in the sql field's description, joined on property_id. Replaces summarize_properties and find_underbuilt_sites.

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": {
      "sql": "<sql>"
    },
    "name": "query"
  }
}

Input Schema

NameRequiredDescriptionDefault
sqlYesOne SELECT or WITH ... SELECT over the views above. Read-only SQL over West Kite's records, for questions the screening tools cannot express: several criteria across views (sales, loans, businesses), exact counts and group-bys, rankings by any column, "which of these also ...". Write ONE PostgreSQL SELECT (CTEs allowed) over these views only, joined on property_id: properties (One row per published property (the same records search shows).): property_id uuid, joins every other view; address street address; city city; neighborhood neighborhood when published; state_fips 2-digit state FIPS (smallint); county_fips 5-digit county FIPS text, e.g. '36005' Bronx, '48201' Harris TX, '12105' Polk FL, '13089' DeKalb GA; apn parcel number; property_type Office, Industrial, Retail, Multifamily, Land, Residential, Hospitality, Mixed use, Civic / institutional; subtype publisher use or subtype text; building_sqft building area; lot_sqft lot area; year_built year built; stories stories; units units; zoning zoning code as published; flood_zone FEMA flood zone when published; owner_name owner of record; owner_type approximate class from the owner name: government, nonprofit, trust, llc, corporation, individual; held_years years since the latest transfer; last_sale_date latest transfer date; last_sale_price latest sale price (null where undisclosed, e.g. Texas); market_value assessor market value; assessed_value assessed value; tax_amount annual tax; valuation_year assessment year; nyc_buildable_sqft NYC only: lot area x City of Yes residential FAR with UAP for the primary district; nyc_unused_buildable_sqft NYC only: buildable minus existing building area; longitude longitude; latitude latitude sales (Recorded transfers linked to properties, one row per property per sale.): property_id uuid; sale_id uuid, shared by every parcel of one deal; sale_date date; recording_date date; price deal amount (null when undisclosed); allocated_price this parcel's share when published; transfer_type deed or transfer type as published; qualification qualified/arm's-length flag as published recorded_loans (New York City recorded mortgages and related documents linked to properties. No term or maturity is recorded.): property_id uuid; document_id ACRIS document id; doc_type mortgage, CEMA, assignment, satisfaction...; recorded_on date; document_on date; amount document amount; lender lender name; lender_kind bank, insurer, nonbank, private, government; lot_count lots the document covers businesses (Businesses registered at property addresses (registrations, not proof of current occupancy).): property_id uuid; business_name name; industries text array; website website; suite suite when published; match_state how the address matched Distance: near(p, <lng>, <lat>, <meters>) in WHERE and distance_m(p, <lng>, <lat>) in SELECT or ORDER BY (p an alias of properties; take the point from a property row or a place you resolved). Always filter properties by state_fips (a number, the first two digits of county_fips: 36 New York, 48 Texas, 12 Florida, 13 Georgia) and county_fips, and keep joins on property_id; use COUNT(*) and GROUP BY for totals; select property_id with the facts so rows link to records. Up to 1000 rows return as a downloadable table the user sees; the planner refuses queries that would scan whole states. Null means unpublished, never zero. On an error, read the message, fix the query and retry once.
titleNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds real behavior: a 1000-row cap returned as a downloadable table, a planner that refuses whole-state scans, the requirement to filter by state_fips and county_fips, 'null means unpublished, never zero', and a retry-once-on-error loop. The only omission is how the downloadable table is surfaced to the agent afterwards.

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 top-level description is three tight, front-loaded sentences with zero waste. However, the operative guidance is packed into a dense multi-hundred-word wall inside the sql parameter, partially duplicating the top-level text ('Read-only SQL over West Kite's records...') and mixing rules, function signatures and a column catalog without strong hierarchy.

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?

For an open-ended SQL tool with no output schema, the definition covers row limits, output form, error recovery and null semantics, which is what an agent needs to call it correctly. What's left implicit is how the query result is presented back (column naming, empty-result handling) and that a title should be supplied for the user-visible table.

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

Parameters5/5

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

The required sql parameter is documented far beyond its type: full view/column inventory with types, the near() and distance_m() helper signatures, mandatory state/county filtering, COUNT/GROUP BY guidance and the 6000-char ceiling context. The only undocumented parameter is the optional title, a minor gap against an otherwise exhaustive spec.

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 the exact mechanism ('Read-only SQL ... One SELECT over the views'), the resource ('West Kite's records'), and the query shapes it covers (counts, group-bys, rankings, distance screens, criteria across sales, loans, businesses). It also names what it supersedes ('summarize_properties and find_underbuilt_sites'), so an agent can separate it from search_properties or the find_* siblings.

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?

Gives a clear selection rule: use this 'for questions the screening tools cannot express' such as multi-view criteria and exact rankings, and notes the join key (property_id). It does not say when *not* to reach for SQL (e.g. prefer search_properties for plain address lookups), so the boundary is implied rather than fully closed.

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.

Resources