Skip to main content
Glama

Save fact

save_fact

Add a fact to the brand's fact library, or with fact_id edit, confirm or reject one. Set from_user only when the user told you the fact in this conversation; it is then confirmed as theirs. A fact you found yourself, on their site, the web or a draft, is proposed with its source_url and waits for the user to confirm it. The same fact is stored once. Free.

Input Schema

NameRequiredDescriptionDefault
kindNonumber: a figure with its period. process: what happens, step by step. example: a named customer or case. claim: anything else the brand states.
textNoThe fact as one self-contained sentence a page could quote.
brandYesBrand or study: its ID from list_brands, or its exact name. A partial name is refused.
statusNoWith fact_id: confirm a proposed fact once the user agrees, or reject it.
fact_idNoEdit this fact, from search_facts. Leave out to add one.
segmentNoThe segment ID or name it applies to; leave out for the whole brand. With fact_id, none makes it brand-wide.
from_userNoTrue only when the user told you this fact in this conversation.
source_urlNoWhere you found it. A new fact needs it unless from_user is true.
stale_afterNoYYYY-MM-DD after which to re-check it, for figures and dated claims. With fact_id, none clears it.
source_excerptNoThe words on the source the fact rests on.
idempotency_keyYesA unique key for this intended action. Reuse it with identical arguments when retrying: the write is not made again, and the reply is the first call's resource as saved (replayed: true) with current status; read tools show the resource's current state. Use a new key for another action.

Output Schema

NameRequiredDescriptionDefault
dataYes
generated_atYesRFC 3339 time the response was made.
schema_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false), and the description adds genuinely useful behavior beyond them: facts are deduplicated ('the same fact is stored once'), user-sourced facts skip the approval wait, and the call is 'Free'. It doesn't clarify permission requirements or what a rejection does to an existing confirmed fact.

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?

Purpose and the add-vs-edit split are front-loaded, and every sentence carries information (dedup rule, source requirement, approval flow, cost). It is dense but not padded, though the middle sentences could be tightened.

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?

For an 11-parameter tool with two enums and an output schema present, the description covers the decision-relevant behaviors: mode selection, sourcing rules, confirmation workflow, and dedup. Return-value details are rightly omitted since an output schema exists.

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 the baseline is 3, but the description adds cross-parameter meaning the schema documents only per-field: the from_user/source_url dependency, the fact_id triggering edit/confirm/reject mode, and the fact_id-absent behavior of clearing segment and stale_after. That is real added value beyond the field-level docs.

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+resource ('Add a fact to the brand's fact library') and distinguishes the two operating modes (add vs. edit/confirm/reject via fact_id). It does not name the read-side sibling search_facts, but the mode split is enough for an agent to place the tool.

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?

Gives real conditional guidance: use from_user only for facts the user stated in-conversation (which are auto-confirmed), and propose self-found facts with source_url so they wait for user confirmation. It stops short of explicitly routing to alternatives like search_facts for reading or save_segment for segment-level facts.

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