noticed

correct_person_claim

Idempotent

Save an explicit user correction, rejection or retraction of a cited person claim, preserving its ID and revision history. Read its current revision first.

Input Schema

Name	Required	Description
`value`	No
`action`	Yes
`reason`	Yes	The user's correction or explanation; never invent a correction on their behalf.
`team_id`	No	Owning Team for Team knowledge; omit for personal knowledge.
`claim_id`	Yes	Canonical claim ID returned by a knowledge section or memory_get.
`validity`	No	Optional correction to the claim validity dates; retain the precision the user supplied.
`rejection_scope`	No	For reject only. Default claim rejects that proposition. Use source_identity only when the user explicitly rejects ownership of the cited source or account: all its facts are excluded. Use record_identity only when the user explicitly rejects the cited record while preserving other records on that page. Never infer this narrower scope from table layout.
`expected_revision`	Yes	Current revision read from the claim; prevents overwriting a concurrent correction.

Output Schema

Name	Required	Description
`ok`	Yes	Whether noticed completed the operation.
`data`	No	The operation result when ok is true.
`error`	No	A human-readable error when ok is false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

addedInput schema / properties / rejection_scope

Added value: +{
+  "description": "For reject only. Default claim rejects that proposition. Use source_identity only when the user explicitly rejects ownership of the cited source or account: all its facts are excluded. Use record_identity only when the user explicitly rejects the cited record while preserving other records on that page. Never infer this narrower scope from table layout.",
+  "enum": [
+    "claim",
+    "source_identity",
+    "record_identity"
+  ],
+  "type": "string"
+}

AddedOct 16, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare non-read-only, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds value beyond them by disclosing the append/preserve semantics ('preserving its ID and revision history') and the concurrency-protection requirement of reading the current revision first, though it says nothing about permissions or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The core purpose is front-loaded and the prerequisite instruction follows immediately.

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 an output schema present, annotations covering the safety profile, and 75% schema coverage across 8 parameters (including nested validity and enum scopes), the description supplies the essentials. It could still note the personal-vs-team scope distinction (team_id) or what the corrected revision returns, but nothing critical is 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?

Schema description coverage is 75%, so the baseline is 3, but the description meaningfully reinforces two parameters: it enumerates the action modes (correct/reject/retract) and ties expected_revision to a concrete retrieval step. It does not clarify value/validity/team_id semantics, which remain schema-only.

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 names a concrete verb-phrase and resource: saving an explicit user correction, rejection or retraction of a cited person claim. Combined with the title and the mention of claim ID and revision history, an agent can distinguish this mutation pathway from generic siblings like update_person or add_memory.

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?

It gives a clear usage context (only for an *explicit* user correction/rejection/retraction, reinforced by the schema's 'never invent a correction on their behalf') and a prerequisite workflow step: 'Read its current revision first.' It does not name alternative tools (e.g., memory_save for new facts), so it stops short of full when/when-not guidance.

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

All noticed tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?