Korzy

Get parcel fields in bulk

enrich

Read-onlyIdempotent

Return selected parcel fields for 1 to 25 items, each an exact address, a longitude/latitude point, or a korzy_id. Choose fields by field or group name, or a preset (not both; default standard). Presets: basic: identity, address, location, land; standard: identity, address, location, land, building, value, sale; owner: identity, address, location, owner. Each item returns up to 20 parcel records or its own error. Costs 1 credit per item, 2x when owner fields are requested (the owner group, any of its fields, or a preset that includes it); failed items are refunded. This is the only source of owner names and mailing addresses; request them only when needed.

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": {
      "items": "<items>"
    },
    "name": "enrich"
  }
}

Input Schema

Name	Required	Description	Default
`items`	Yes
`fields`	No
`preset`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds context they cannot: 1 credit per item, 2x for owner fields, refunds for failed items, and up to 20 records returned per item with per-item errors. That is exactly the economic and result-shape information an agent needs to decide batch size and field selection.

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?

Dense but front-loaded: scope first, then selection semantics, then presets, then cost. Every sentence carries information, though the preset expansions are compact lists that trade readability for brevity.

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?

An output schema exists, so return structure need not be restated; the description covers the remaining unknowns an agent would hit, namely batch limits, item shapes, field/preset conflict, per-item failure behavior, and credit cost.

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 description coverage is 0%, so the description must carry parameter meaning, and it does: item types map to the anyOf branches, the 1-25 bound matches maxItems, and the fields/preset exclusivity and preset contents are spelled out. It stops short of explaining individual field names or units (e.g. taxacres, saleamt), which remains a gap given 48 enum values.

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 ('Return selected parcel fields') plus the unit of work ('for 1 to 25 items') and the three accepted item kinds. An agent can immediately distinguish it from get_record (single record) and list_fields (field discovery).

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?

Says fields and preset are mutually exclusive with 'standard' as default, and adds a real steered condition: 'This is the only source of owner names and mailing addresses; request them only when needed' because of cost. It does not explicitly say when to prefer this over get_record or lookup, so the routing is implied rather than named.

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

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

Resources

Need Help?