Skip to main content
Glama
people-context

people-context

get_consolidation_context

Read-only

Retrieve a person's stored facts, traits, observations, affiliations, and relationship signals to review evidence before proposing record corrections, fact supersessions, or people merges.

Instructions

Return one person's stored facts, traits, observations, and affiliations and how they relate.

Pass person_id from resolve_person, or person (a name or alias) to resolve inline.

Use this before proposing maintenance. signals names pairs of records that share a predicate or category and says how they stand — duplicate_fact, restated_fact, contradictory_fact, succeeding_fact, duplicate_trait, divergent_trait — comparing normalized values and inclusive validity periods only. It decides nothing: reading the evidence and proposing a correct_record, a supersede_fact, or a merge_people for the user to approve is your job, and several observations supporting one trait are separate evidence rather than duplicates.

affiliations carries the person's stored roles at organizations — employment, education, membership — with their ids, dates, provenance, and any import receipt, so an incoming CV claim can be checked against what is already recorded. It has its own page and its own affiliations_truncated flag, and no signal is computed over it: two roles at one organization may be a promotion, a rehire, or two concurrent posts, and only you can read which. A valid_to of null means the stored assertion set no end, not that the role is confirmed current, and created_at is when the row was written rather than when the role began. A page that truncates is not evidence that a role is absent.

This read never writes. Sensitive and restricted records are never returned, and a trait names only evidence that is itself ordinary. Affiliations carry no disclosure level at all, so this collection adds no sensitivity control and is no route to a protected fact — background that needs one belongs in a fact. An unknown or removed person returns found: false rather than an error.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_consolidation_context"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
personNo
person_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.0
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "get_consolidation_contextDictOutput",
      -  "type": "object"
      -}New value: +null
  2. First observedv1.1.1

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only supply readOnlyHint=true, and the description adds substantial context beyond that: sensitive and restricted records are never returned, affiliations carry no disclosure level, unknown or removed persons yield found: false rather than an error, valid_to null does not mean currently confirmed, created_at is row-write time not role start, and truncation is not evidence of absence. It also discloses the exact signal vocabulary and, importantly, the limits of that vocabulary (normalized values and inclusive validity periods only, several observations are separate evidence rather than duplicates).

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 structure is logical and front-loaded: purpose, then input routing, then signals, then affiliations caveats, then safety and error behavior. It is long and dense with no formatting, and "This read never writes" restates readOnlyHint, but nearly every other sentence carries non-obvious information that would otherwise be lost.

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?

With no output schema, the description does the heavy lifting on returns: the signal types and what they mean, the separate affiliations collection with its own page and truncation flag, and the found: false failure mode. It falls short on the shape of the primary facts/traits/observations payload and on how limit governs paging, which an agent needs to interpret truncation correctly.

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 0%, so the description must carry parameter meaning, and it does well for two of three: person_id is sourced from resolve_person and person accepts a name or alias resolved inline. The limit parameter is never mentioned, leaving its role in pagination and its interaction with the affiliations_truncated flag unexplained.

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?

The first sentence names a specific verb and resource set: stored facts, traits, observations, and affiliations for one person, plus how they relate. The follow-up sentences scope it further as pre-maintenance evidence gathering, which is distinguishable from siblings like get_person_context or search_people even though those are not named directly.

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?

"Use this before proposing maintenance" gives an explicit trigger, and the description names the follow-on tools (correct_record, supersede_fact, merge_people) plus resolve_person for ID acquisition. It also carves out that this tool decides nothing, leaving judgment to the agent. What is missing is an explicit contrast with get_person_context, which an agent would reasonably consider as an alternative.

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