Skip to main content
Glama

add_evidence

Idempotent

Record supporting, contradicting, or sourced-from evidence for a memory, rejecting duplicate relations to keep memory provenance accurate.

Instructions

Record evidence for a memory. relation="supports"/"contradicts" links evidence_id → memory_id (a memory supporting or contradicting it); relation="sourced_from" records memory_id's external provenance via source (URL/document). Writes one relation and returns its relation_id; an identical relation is rejected rather than duplicated. Contradictions accelerate the contradicted memory's decay; superseded or archived evidence stops counting. Requires agent auth when the agent has a registered key.

Input Schema

NameRequiredDescriptionDefault
sourceNoExternal source: URL, document path, conversation reference (required for sourced_from).
api_keyNoAPI key for agent authentication (required if agent has a registered key)
agent_idNoID of the requesting agentunknown
relationYesEvidence relation: "supports" | "contradicts" | "sourced_from". supports/contradicts link two memories (`evidence_id` = the memory providing evidence); sourced_from records an external source text.
memory_idYesThe memory this evidence statement is ABOUT, or that the subject memory supports/contradicts — see `relation` for direction. For supports/contradicts: the memory being supported/contradicted. For sourced_from: the memory whose provenance is recorded.
confidenceNoEvidence confidence, 0.0-1.0 (default 0.8).
evidence_idNoThe memory providing evidence (required for supports/contradicts).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that duplicates are rejected rather than created (concretizing idempotentHint), that contradictions accelerate the contradicted memory's decay, that superseded or archived evidence stops counting, and that a relation_id is returned. Auth requirement is also stated. These are real side effects and constraints an agent could not infer from the structured fields.

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?

Front-loads the core purpose, then mode semantics, then side effects and auth — a sensible order. Dense but every clause carries information; only the parenthetical re-explanation of supports/contradicts is mildly redundant with the relation schema description.

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 7-parameter write tool with no output schema, the description covers return value (relation_id), failure mode (duplicate rejection), downstream consequences (decay acceleration, superseded evidence), and auth. Nothing essential for a correct call 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 coverage is 100% so baseline is 3, but the description adds genuine meaning: it clarifies the direction of the evidence_id → memory_id arrow and what `source` does for sourced_from. It does not explain `confidence` or `agent_id`, leaving those entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Record evidence for a memory") and spells out the two modes of the operation (memory→memory relations vs memory→external source provenance). An agent can see this is a write of a single relation, unlike the read-oriented get_memory_evidence sibling, but no sibling is named explicitly, so it falls short of a 5.

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?

Clear conditional guidance per mode: relation="supports"/"contradicts" link evidence_id → memory_id, relation="sourced_from" requires `source`. Prerequisites (agent key auth, source required) are stated. It does not, however, say when an agent should prefer this over save_memory or get_memory_evidence, or when not to use it.

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