PersonIQ

Full property report from a street address

unlock_property_by_address

Buy the FULL property report for a specific street address: owner identity and contact data, valuation, tax and sale history, and distress signals. Use this when you have an address and need owners — lookup_property returns characteristics with owner names MASKED and does not reveal them. Costs 8 credits (quote first, then confirm), and runs as a job: poll get_job for the result. Recalled free if you already own the report for this property.

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": {
      "street": "<street>"
    },
    "name": "unlock_property_by_address"
  }
}

Input Schema

Name	Required	Description
`zip`	No	ZIP code. Sufficient on its own alongside street.
`city`	No	City. Required unless zip is given.
`state`	No	Two-letter state code. Required unless zip is given.
`format`	No	Rendering of the human-readable text channel. "prose" (default) is a compact summary an agent can reason over; "json" repeats the data verbatim; "report" is a formatted Markdown report to show a person; "html" is a standalone HTML document for saving, printing or PDF. Machine-readable structuredContent is always included either way.
`street`	Yes	Street address, e.g. 123 Main St.
`confirmToken`	No	Omit to receive a quote; pass the quoted token to start the job.

Output Schema

Name	Required	Description	Default
`data`	Yes
`apiVersion`	Yes
`disclaimer`	Yes
`balanceNotice`	No
`suggestedNext`	No
`criminalCaveat`	No
`notConsumerReport`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, openWorldHint=true and destructiveHint=false; the description adds the economically critical facts the annotations cannot convey — an 8-credit cost, a required quote-then-confirm two-step before any charge, and asynchronous job execution requiring a poll of get_job. It also discloses the caching/no-recharge rule for already-owned reports, which materially affects whether an agent should call it at all.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, front-loaded with the deliverable, then the decision rule, then cost and async mechanics — no filler and nothing repeated from the annotations. Each sentence carries a distinct decision-relevant fact.

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 paid, asynchronous, single-required-parameter tool, the description covers cost, consent flow, job polling, caching, and return contents; an output schema exists so field-level return documentation is unnecessary. Nothing an agent needs in order to invoke it correctly, or to avoid invoking it wrongly, is missing.

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 and the schema already documents street, zip, city, state, format and confirmToken. The description nonetheless adds meaning the schema does not: it frames confirmToken as a credit-spending decision point ('quote first, then confirm'), telling the agent the first call is free and non-committal. The rendering/format parameter is left entirely to the schema, keeping this below a 5.

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 — 'Buy the FULL property report for a specific street address' — then enumerates what the report contains (owner identity/contact, valuation, tax and sale history, distress signals). It explicitly contrasts with the sibling lookup_property, which returns masked owner names, so an agent can choose between them 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 Guidelines5/5

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

Gives an explicit when-to-use condition ('when you have an address and need owners'), an explicit when-not/alternative ('lookup_property returns characteristics with owner names MASKED and does not reveal them'), and the operational sequence ('quote first, then confirm'). It also names a second alternative path implicitly by noting the report is recalled free if already owned, which suppresses a redundant purchase.

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

All PersonIQ 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?