Skip to main content
Glama

Enrich an existing subject

enrich_subject
Idempotent

Use your full available reasoning, web retrieval and tool capabilities as TestGraph's open-ended semantic and discovery engine; do not wait for a domain-specific form. TestGraph supplies graph primitives and verification while you derive useful structure and reconcile evidence. Add missing identifiers, attributes, provenance and related unreviewed subjects to an existing subject without creating another review. Use this proactively when authoritative information was missed during the original save. Find only authoritative facts with plausible future TestGraph use: identity, likely queries, location, classification, relationships, comparison or verification. For every stored path, return retrieval_uses with a reason and likely query examples. Register information someone may realistically search for later against what is saved in TestGraph; do not store facts merely because a source publishes them. Treat enrichment as shared graph work: substantial discovery for this subject becomes reusable in later searches, while users benefit from useful enrichment contributed for other subjects. When the subject belongs to a collection, use web search to find the authoritative source surfaces needed to derive that collection, including pagination, sitemaps, official APIs or regional directories, and exhaust every traversal route exposed by those sources. Submit source_manifest mapping every member to its consulted source pages, then submit every discovered member as an unreviewed subject and connect it to the collection. Do not omit members because they are unreviewed, numerous or may be materialised later. Do not ask the user for routine lookup permission unless automatic lookup is unavailable or identity is genuinely ambiguous. Existing conflicting values are preserved rather than silently overwritten. When the client supports concurrent tool calls, submit independent writes concurrently in batches of up to 10. Do not batch dependent operations until their prerequisites are confirmed. Reuse the same canonical key for the same subject and derive deterministic idempotency keys from a stable run identifier, target and operation so retries and restarted conversations safely return existing writes instead of creating duplicates. WORKFLOW: the server now owns the post-enrichment procedure. A successful response includes durable workflow state and the next required classification action. workflow.next_action names an exposed MCP tool; call it with workflow.next_action_arguments and follow workflow.next_action_instruction rather than reconstructing the procedure yourself.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
attributesNo
provenanceNo
subject_idNoPreferred stable subject locator returned by search, fetch or save_experience.
identifiersNo
subject_typeNo
canonical_keyNo
idempotency_keyYes
subject_contextNoOptional related subjects and relationships. Use subject as the reserved ref for the existing subject being enriched.
collection_assessmentYesRequired collection assessment for enrichment. For member status, use subject as the existing target ref, discover every authoritative source surface, submit an exhaustive source_manifest, and submit the target plus every derived sibling. unavailable is only for genuine collection-identity or authoritative-source failure; it is invalid when collection evidence is known and cannot be used for size, effort, inconvenience, latency, quick-review scope or deferred work.
subject_enrichment_checkYesRequired evidence check for this enrichment. Reconcile sources against identifiers, attributes, provenance or subject_context request paths.

TDQS

A4.8/5.0
Behavior5/5

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

The description adds substantial operational detail beyond annotations: it explains deterministic idempotency keys for safe retries, preserves existing conflicting values, batches concurrent writes up to 10, and reveals that a successful response includes durable workflow state with a next_action tool to call. These details are not present in the annotations and meaningfully shape agent behavior.

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 and dense, but it is front-loaded with the core purpose and then structured into usage, behavior, collection handling, and workflow sections. Every sentence contributes a rule or constraint, though some repetition occurs (e.g., 'do not omit members'), making it slightly less concise than ideal.

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, no output schema, and rich nested parameters, the description is remarkably complete. It covers the full lifecycle: what to enrich, how to handle identity and provenance, collection discovery with source manifests, idempotency and concurrency, and the post-enrichment workflow involving next_action. An agent has enough guidance to invoke the tool correctly in most scenarios.

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 schema description coverage around 40%, the description compensates by giving meaning to key parameters: idempotency_key via deterministic key derivation, canonical_key via reuse guidance, retrieval_uses via required reasons and likely query examples, and source_manifest via exhaustive source-surface mapping. It does not individually document every parameter, but the operational instructions clarify the most important ones.

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 description opens with a specific verb and resource: 'Add missing identifiers, attributes, provenance and related unreviewed subjects to an existing subject without creating another review.' It clearly distinguishes enrichment from review creation and gives a precise account of what the tool accomplishes.

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?

It states explicitly when to use the tool: 'Use this proactively when authoritative information was missed during the original save.' It also provides exclusions, such as not asking for routine permission, not storing facts merely because a source publishes them, and not omitting unreviewed collection members, giving clear boundaries versus alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation3/5

Most tools are separated by resource and action, but the classification cluster (affirm_subject_classification, propose_subject_reclassification, reopen_subject_classification, get_subject_classification) and the three resolve_subject* tools require close reading to distinguish. Long descriptions help, but an agent could easily pick the wrong member of those clusters.

Naming Consistency4/5

The dominant pattern is verb_noun in snake_case (create_deliberation, list_reviews_by_visibility, resolve_subject_type, set_review_visibility). Minor deviations such as bare 'fetch' and 'search' and mixed verbs like affirm vs propose vs reopen are readable and do not break the convention.

Tool Count2/5

34 tools substantially exceeds the 25+ threshold even for a server with multiple subdomains. The many classification, type, and location variants add cognitive load, and several could be consolidated or hidden behind a smaller workflow-oriented surface.

Completeness4/5

The set covers the main lifecycles: review save/fetch/assess/delete/visibility, subject resolution/enrichment/correction, classification with voting/reopening, deliberations, locations, and vocabulary management. Minor gaps remain, such as no direct full-subject getter and no update to review text, but these appear intentional in an immutable-review design.