Skip to main content
Glama

Correct an existing subject fact

correct_subject_fact
DestructiveIdempotent

Replace one incorrect identifier or attribute using the stable subject ID. The current value must match expected_value, authoritative evidence and a reason are mandatory, and the server preserves an immutable correction record in subject provenance. Use enrich_subject for missing facts; never use this operation merely to add a value. WORKFLOW PRECONDITION: for an existing subject, the server checks classification before mutation. The authenticated user may always enrich a subject they own or one attached to their own non-deleted review without waiting for another AI, including while classification is disputed. Ownership is determined by the authenticated user, not the AI client; all other evidence and write validations still apply. Enrichment does not confirm or resolve classification. For other contributors, an unsettled subject returns classification_review_required or classification_resolution_required without applying the requested update. Complete the returned durable workflow, then retry the unchanged request with the same deterministic idempotency key. You must not report the update as complete when this prerequisite is returned. WORKFLOW: after every successful write, inspect workflow.workflow_action_required. When it is true, you must follow workflow.next_action with workflow.next_action_arguments and workflow.next_action_instruction for the classification decision. When independent review or dispute resolution is pending, leave that classification action pending and continue requested enrichment of the authenticated user's own subject or one attached to their own non-deleted review. Report a successful enrichment separately from the still-pending classification.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonYes
field_pathYesDot-separated path below field_root.
field_rootYes
subject_idYes
expected_valueYes
corrected_valueYes
idempotency_keyYes
evidence_sourcesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / version_check
      Removed value: -{
      -  "description": "Required live deployment token. Call get_server_info immediately before this write and pass write_version_token unchanged. Stale or missing tokens are rejected before any write occurs.",
      -  "maxLength": 64,
      -  "minLength": 64,
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "subject_id",
      -  "field_root",
      -  "field_path",
      -  "expected_value",
      -  "corrected_value",
      -  "evidence_sources",
      -  "reason",
      -  "idempotency_key",
      -  "version_check"
      -]New value: +[
      +  "subject_id",
      +  "field_root",
      +  "field_path",
      +  "expected_value",
      +  "corrected_value",
      +  "evidence_sources",
      +  "reason",
      +  "idempotency_key"
      +]
  2. Changed2 schema fields changed
    • addedInput schema / properties / version_check
      Added value: +{
      +  "description": "Required live deployment token. Call get_server_info immediately before this write and pass write_version_token unchanged. Stale or missing tokens are rejected before any write occurs.",
      +  "maxLength": 64,
      +  "minLength": 64,
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "subject_id",
      -  "field_root",
      -  "field_path",
      -  "expected_value",
      -  "corrected_value",
      -  "evidence_sources",
      -  "reason",
      -  "idempotency_key"
      -]New value: +[
      +  "subject_id",
      +  "field_root",
      +  "field_path",
      +  "expected_value",
      +  "corrected_value",
      +  "evidence_sources",
      +  "reason",
      +  "idempotency_key",
      +  "version_check"
      +]
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The description goes well beyond the annotations. It discloses that the server preserves an immutable correction record in subject provenance, that the server checks classification before mutation, that ownership is determined by the authenticated user rather than the AI client, and that enrichment does not confirm or resolve classification. It also explains the post-write workflow requirement to inspect workflow.workflow_action_required and follow next_action. This is rich behavioral context that the annotations alone do not provide.

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 information-dense, and the most critical information is front-loaded: the core operation, the distinction from enrich_subject, and the mandatory evidence/reason requirements appear in the first two sentences. The workflow details are lengthy but necessary for correct invocation. It earns a 4 rather than 5 because the workflow section is somewhat sprawling and could be tightened without losing meaning.

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 mutation tool with 8 required parameters, no output schema, and complex workflow requirements, the description covers the essential context: what the tool does, when to use it, what the server checks, how ownership works, how to handle prerequisite responses, and what to do after a successful write. The only minor gap is that it doesn't describe the response shape, but since there is no output schema and the workflow instructions reference specific response fields, the description provides enough guidance for an agent to proceed.

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 only 13%, so the description must compensate for the schema's lack of parameter documentation. The description explains the semantics of expected_value ('The current value must match expected_value'), evidence_sources and reason ('authoritative evidence and a reason are mandatory'), and idempotency_key ('retry the unchanged request with the same deterministic idempotency key'). However, it does not explain field_root, field_path, corrected_value, or subject_id beyond what the schema provides. Given the low coverage, the description adds some value but leaves several parameters under-explained.

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: 'Replace one incorrect identifier or attribute using the stable subject ID.' It clearly distinguishes the tool from enrich_subject by stating that enrich_subject is for missing facts and that this tool is never to be used merely to add a value. This makes the purpose unmistakable and differentiates it from its closest sibling.

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 provides explicit when-to-use and when-not-to-use guidance: 'Use enrich_subject for missing facts; never use this operation merely to add a value.' It also details the workflow precondition for ownership and classification state, including what happens for other contributors and how to handle the returned durable workflow. This is comprehensive usage guidance.

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.

Resources