Homesage.ai MCP

Skip Trace: Person Details

skip_trace_person_details

Read-only

What it returns

Full skip-trace dossier for a single person — current and previous addresses, phone numbers (with type and connectivity status), email addresses (with verification status), relatives, and associates. The person_id input must come from a prior call to skip-tracing/associated-people — this endpoint does not accept free-form name lookup.

When to use it

You have a person_id from associated-people and want full contact details before reaching out.
You're enriching a CRM record with verified phones/emails for a known person.
You need historical address data to verify identity or reconstruct timelines.

Pricing

1 credit per call. A first call for a given person_id hits the upstream provider; subsequent calls within the per-user history cache are free. Identical calls from other accounts hit a shared global cache but still cost 1 credit (the data has value; the speed is the gift).

Errors

Status	Meaning
400	Missing `person_id` field, or `person_id` not recognized by the provider.
401	Authentication failed.
402	Insufficient credits.
502	Upstream skip-tracing microservice unavailable. Safe to retry with exponential backoff.

FAQ

How fresh is the data?

The upstream provider refreshes records on its own cadence; we don't control it. For privacy-sensitive use cases, treat addresses older than 12 months as stale.

What's the difference between this and `skip-tracing/associated-people`?

associated-people returns a list of people tied to a property address with minimal detail per person (name, relationship inference, person_id). This endpoint takes one of those person_ids and returns the full dossier for that one person. Use them together: list → drill down.

Why might `current_addresses` be empty?

The provider has no current-address record for the person. This is common for transient or recently deceased individuals.

Is the data court-admissible?

No. Skip-trace data is research-grade aggregation of public records and is not certified for legal proceedings.

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": {
      "person_id": "<person_id>"
    },
    "name": "skip_trace_person_details"
  }
}

Input Schema

Name	Required	Description	Default
`person_id`	Yes	Stable identifier returned by `skip-tracing/associated-people` for a specific person. Not a free-form name — must come from a prior skip-trace call.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false) and open-world reach, but the description goes well beyond them: credit cost and per-user vs. global cache behavior, a per-status error table with retry guidance for 502, data-freshness caveats, and an explicit non-admissibility warning. The only gap is that caching semantics are described conceptually rather than as a precise rule, but the behavioral surface is otherwise unusually well disclosed.

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?

Front-loaded with the two highest-value sections (what it returns, when to use it) before pricing and errors, and headings plus a table make it scannable. It runs long, and the FAQ's court-admissibility and empty-`current_addresses` entries are useful but not essential to invocation, so it falls short of perfectly economical.

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?

Given a one-parameter read-only tool with a full output schema, the description supplies everything the agent needs beyond structured fields: the chaining prerequisite, cost model, retry behavior on 502, and freshness caveats. Nothing material to correct invocation or interpretation is missing.

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 coverage is 100% for the single `person_id` parameter, and the schema already states it must come from a prior skip-trace call and is not a free-form name. The description restates that constraint and adds a little meaning via the 400 error case ('not recognized by the provider'), but most of the semantic load is already carried by the schema, so this sits at the high-coverage baseline.

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?

Opens with a specific verb and resource — 'Full skip-trace dossier for a single person' — then enumerates exactly what the dossier contains (addresses, phones with connectivity status, emails with verification, relatives, associates). It explicitly contrasts itself with the sibling `skip-tracing/associated-people`, so an agent can separate list vs. drill-down without inspecting 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?

Provides three concrete when-to-use scenarios (pre-outreach enrichment, CRM enrichment, identity/timeline verification) plus a hard prerequisite: the `person_id` must originate from a prior `associated-people` call. The FAQ reinforces the pairing pattern ('list → drill down'), leaving no inference required about when this tool is the right pick.

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

All Homesage.ai MCP tools Inspect

Try in Browser