Skip to main content
Glama

Find signed facts for a place, as citable sources

search
Idempotent

Find signed facts as citations for a place, question, cell handle, or existing citation; returns one cited fact or a capped list with the true total.

Instructions

Search emem's signed corpus and get results as citations. Each entry is one signed fact. It has an id to dereference, a title with band, place and signed value, and a stable url that serves those bytes. The query can be a place or a question about one. ('NDVI near Mount Fuji': a topic word narrows the results and never removes all of them.) It can also be a cell64, an emem:cell: handle, or an emem citation, which returns the one fact it cites. The list has a cap for the wire. The first entry (index 0) names the cell and the TRUE total. On a cold cell, the tool MATERIALIZES a missing band first, as emem_recall does: it fetches, signs and stores it. Thus readOnlyHint false.

When to use: Call this first when a question is about a place and the answer must have citations. It changes the question into a list of sources, and fetch expands each source. For one combined answer in one call, use emem_ask.

Example arguments: {"query":"Trafalgar Square, London"}

Input Schema

NameRequiredDescriptionDefault
queryYesA place, a question about one, a cell64 or emem:cell: handle, or an emem:fact: citation.

Output Schema

NameRequiredDescriptionDefault
resultsYesThe FIRST entry (index 0) is the cell itself, carrying the true total, so a capped list still says how much there was; after it, one entry per signed fact.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.4.4

TDQS

A4.6/5.0
Behavior4/5

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

Annotations (readOnlyHint false, openWorldHint true, idempotentHint true, destructiveHint false) are explicitly reconciled — the description explains that a cold cell causes materialization (fetch, sign, store), which is why readOnlyHint is false. It also discloses the wire cap and that index 0 carries the TRUE total. The remaining gap is that band/cell jargon is undefined and no rate or cost behavior is mentioned.

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 purpose, then result shape, then query semantics, then when-to-use and an example — a sound order with little waste. A few phrasings are cryptic ('cap for the wire', 'cell64', 'band') and cost it the top score.

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?

An output schema exists, so explaining return values is optional, yet the description still sketches the entry structure and the index-0 convention. Combined with an explicit when-to-use, the alternative, and the materialization caveat, an agent has everything needed to call it correctly.

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 goes beyond it: a topic word narrows results without ever emptying them, and a cell64/handle/citation input resolves to the single cited fact. That adds behavioral meaning the schema's enumeration does not convey.

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?

States a specific verb and resource — searching emem's signed corpus and returning each signed fact as a citable source — and immediately describes the result shape (id, title with band/place/signed value, stable url). It is clearly differentiated from siblings by naming fetch as the expander and emem_ask as the combined-answer alternative.

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?

An explicit 'When to use' block says to call this first when the question is about a place and the answer must have citations, and names the alternative (emem_ask) with the condition that selects it. It even notes the input can be a citation handle, which returns exactly one fact.

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