Ogen

Recall a live fact

recall_live_fact

Read the live value bound to a key, right now — every recall reads the live source at the moment of the question, nothing is cached as truth. Returns resolved with a value, ambiguous with every candidate and an instruction not to choose between them, or unavailable. Pass key for one fact, or keys for up to 25 in one call — each answered independently, so one unresolved key never changes another's answer. Free and pro.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`key`	No	One bound key to recall, e.g. 'customer.acme.address'. Give key or keys, not both.
`keys`	No	Instead of key: 1 to 25 bound keys, e.g. ['customer.acme.address', 'order.42.status']. Duplicates are read once.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 26, 2026

changedInput schema / properties / key / description

Previous value: -"The bound key to recall, e.g. 'customer.acme.address'."New value: +"One bound key to recall, e.g. 'customer.acme.address'. Give key or keys, not both."

addedInput schema / properties / keys

Added value: +{
+  "description": "Instead of key: 1 to 25 bound keys, e.g. ['customer.acme.address', 'order.42.status']. Duplicates are read once.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 25,
+  "minItems": 1,
+  "type": "array"
+}

removedInput schema / required
```
Removed value: -[
-  "key"
-]
```

First observedSep 24, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Though no annotations are provided, the description is very transparent about behavior: it reads live source, returns specific states, and ensures independent resolution. It discloses that nothing is cached, which is a key behavioral trait. However, it doesn't mention potential errors beyond 'unavailable' or rate limits, but given the detail, it earns a 4. There is no contradiction with annotations since none are present.

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?

The description is a single, well-structured paragraph that front-loads the core purpose ('Read the live value bound to a key'), followed by behavioral details and usage examples. Every sentence adds meaningful information without redundancy. It's concise yet comprehensive, earning a 5.

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?

Given the tool's moderate complexity (two parameters, no output schema, no annotations), the description covers the essential aspects: what it does, return states, parameter usage, and limitations. It doesn't explain the return format in detail (e.g., JSON structure), but since no output schema exists, that might be expected. It could mention error scenarios, but it already covers 'unavailable' and independence, so it's largely complete.

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?

The schema already provides descriptions for both parameters (key and keys), including examples and maxItems. The description adds value by explaining that one can pass either key or keys, not both, and that duplicates are read once, which goes beyond the schema. Since schema coverage is 100%, the baseline is 3, but the extra clarification on the mutual exclusivity and duplicate handling elevates it to 4.

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 clearly states the action (read live value) and the resource (a key). It explicitly says 'every recall reads the live source at the moment of the question, nothing is cached as truth,' which is a distinctive behavioral trait that differentiates it from siblings like audit_log or what_it_caught. It also clarifies the return states (resolved, ambiguous, unavailable), which aids in correct invocation.

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?

The description provides clear context on when to use this tool (to read live facts) and how to use it (pass key or keys). It doesn't explicitly state when not to use it or mention alternatives like discover_fields, but the focus on 'live' and 'uncached' gives strong guidance. The mention of 'up to 25' keys and independence of answers is a usage guideline.

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

All Ogen tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?