Skip to main content
Glama
JinyangWang27

people-context

stage_candidates

Stage extracted people, interactions, relationships, groups, and memberships as structured candidates for import. Use after extracting from notes or transcripts.

Instructions

Stage agent-extracted people, interactions, records, relationships, groups, and memberships.

Candidate types are person, interaction, affiliation, fact, observation, trait, relationship, group, and group_membership.

Use this after extracting concise candidates from user-provided notes, meeting transcripts, or other agent-visible text. Distinguish what was stated (fact), what happened in this source (observation), and what you inferred (trait, which requires an explicit confidence and a concise evidence_note). Relationship candidates carry batch-local from_ref/to_ref and are ordinary-disclosure only: omit a relationship the user would consider sensitive or restricted rather than staging it.

References are batch-local; raw notes and source text must not be included in candidate fields. A request using observation, trait, or relationship is bounded to 500 candidates, a 128-character source, 1 MiB of candidate JSON, and 8 KiB per string.

A fact or affiliation may record who asserted it in an optional stated_by of at most 256 characters: a person, a document, or a role. Attribution is not verification. A CV saying someone is analytical is that person's own claim about themselves, so stage it as a fact whose value says so and whose stated_by names them, never as an inferred trait. stated_by is separate from source, which names the process that wrote the row, and from source_kind below, which receipts the artifact read. Omit it when the attribution is unknown rather than guessing at a speaker.

A trait may name the records it was drawn from. Give a supporting observation or interaction any short evidence_ref label of your own and list those labels in the trait's evidence_refs; use evidence_ids for records already stored. Evidence must be about the trait's own person, and one trait cites at most 32 references and ids combined, each at most 256 characters.

A shared context is two candidates, never one. A group names an identified class, cohort, team, department, club, household, or community and carries a batch-local ref; a group_membership places one person_ref in one group_ref with a role, and requires a batch that passes source_kind, so a group committed in an earlier call can still be named. Group names never merge: staging looks nothing up by name, so committing a group candidate creates a new group unless you pass group_id — resolve an existing group with find_groups first and pass the id it returns. Record dates only where the source gave them. Absent dates stay absent and mean unknown, never "still going": temporal_basis is unknown without dates, period with them, and ongoing only when you set it because the source said so. Do not invent a year, a class number, or a yearly placement per grade; a confirmation that people stayed together records the people and the extent that were confirmed, and nothing more. "My classmate" with no identified group is a relationship, not an invented group.

source_kind optionally records an import receipt for this batch. It is a machine category such as meeting_transcript, at most 128 characters of letters, digits, ., _, -, or / — never a person, a title, or a description; put any human wording in label instead. If you can compute a SHA-256 over the exact source artifact, pass it as content_digest (64 lowercase hex characters) so re-importing that same source can be detected; without one, no duplicate detection is promised. extraction_fingerprint is optional and should be omitted unless you have explicit, bounded configuration semantics for it. None of these fields may carry source text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelNo
sourceYes
candidatesYes
source_kindNo
content_digestNo
external_source_idNo
extraction_fingerprintNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only provide generic hints (not read-only, not idempotent, not destructive). The description goes far beyond that, disclosing hard limits (500 candidates, 128-char source, 1 MiB JSON, 8 KiB per string), duplicate-detection behavior via content_digest, the lack of name-based lookups, group merge semantics, and date/time inference rules. This is substantial behavioral context that an agent needs to avoid mistakes.

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 description is long but well-structured, with clear topic paragraphs for candidate types, attribution, groups, dates, and source fields. Every sentence adds necessary rules or constraints, and the most important purpose statement is front-loaded. It is not concise in absolute terms, but for a tool with this many nuanced rules, the length is appropriate, though it could potentially be tightened by moving some edge-case rules to a separate reference.

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 the tool's complexity, the description covers all critical domains: candidate types and their distinctions, attribution semantics, group references, date handling, source receipt fields, limits, and when to omit candidates. Because an output schema exists, return values are presumably specified there, so the description's focus on input semantics is appropriate. No essential information appears 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?

With 0% schema description coverage, the description must explain every parameter. It thoroughly covers `source`, `candidates`, `source_kind`, `content_digest`, and `extraction_fingerprint`, and touches `label` in the context of human wording. However, `external_source_id` is never mentioned, leaving one parameter undocumented. Still, the breadth and depth of the provided semantics are excellent, so only a small deduction is warranted.

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 states a specific verb and resource: 'Stage agent-extracted people, interactions, records, relationships, groups, and memberships.' This clearly distinguishes the tool from siblings like commit_import, review_import, or record_fact. Subsequent lines enumerate exact candidate types, leaving no ambiguity about the tool's scope.

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?

The description explicitly says 'Use this after extracting concise candidates from user-provided notes, meeting transcripts, or other agent-visible text.' It also gives exclusions, e.g., omit sensitive relationships rather than staging them, and names an alternative: 'resolve an existing group with `find_groups` first.' These are clear usage conditions and alternative routes.

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