Skip to main content
Glama

confirm_fact

You saw a pattern happen again. Bumps its confirmations and stamps today, which is what makes it outrank weaker patterns when context is tight — and what stops it decaying out of the snapshot after six months unobserved. Silent, no card: counting an observation is not a claim about the athlete. Use it instead of writing the same pattern twice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
noteNooptional: what you saw this time, appended to the fact

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The description reveals concrete behavioral effects: confirmations are incremented, today's date is stamped, ranking is increased, decay after six months is prevented, and the operation is silent with no card. This goes well beyond the sparse annotations (readOnlyHint, openWorldHint, destructiveHint) and no output schema.

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?

Three sentences with no filler; the trigger is front-loaded and each clause earns its place by explaining a behavioral consequence. The ranking/decay aside is dense but directly relevant to why confirmation matters.

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 a two-parameter confirmation tool with no output schema, the description fully covers the situation, side effects, and semantic boundary. The only small gap is that it never states what the function returns, but this is low-stakes for a tool described as 'silent'.

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?

Only 50% of the parameters have schema descriptions, and the description does not directly explain the id parameter beyond implying it identifies the pattern/fact. The note parameter is already well described in the schema ('what you saw this time, appended to the fact'), so the description adds no additional parameter value.

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 the exact trigger, 'You saw a pattern happen again,' and states the core action: record a repeat observation by bumping confirmations and stamping today. It distinguishes confirm_fact from add_fact/update_fact by explicitly telling the agent to use it instead of writing the same pattern twice.

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 gives a when-to-use condition (a pattern is observed again) and an explicit alternative ('instead of writing the same pattern twice'), routing the agent away from creating duplicate facts. The additional note that confirmation is not a claim about the athlete provides a clear exclusion for what the tool is not for.

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