Skip to main content
Glama

k-NN over the corpus by embedding

emem_find_similar
Read-onlyIdempotent

Find similar places by cell embedding or inline vector. Returns k nearest neighbors using cosine, Hamming, or combined similarity.

Instructions

k-NN over the corpus by cell embedding or inline vector.

When to use: Call when the user asks 'find places like X', 'where else looks like this', or hands an embedding to find neighbours. key is either a cell64 or inline:[x,y,...]. Default band is geotessera (128-D Tessera foundation embedding); pass band: "geotessera.multi_year" for the 1152-D 9-vintage (2017–2025) fusion.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kNo
keyYescell64 (look up that cell's vector) or 'inline:[x,y,...]' literal vector
bandNovector band to scan (default: 128-D Tessera foundation embedding). For mode=hamming/hamming_then_rerank you can pass either the cosine band (e.g. 'geotessera') or its binary sibling ('geotessera.bin128') — the responder picks the right one.geotessera
modeNoScoring mode. cosine = fp32 over full vector (precise, ~256 B/cell scan). hamming = sign-bit popcount over the binary sibling band (~16 B/cell, ~1000× faster, ~65% recall@10). hamming_then_rerank = triage with Hamming on 4·k candidates then re-rank by cosine — matches cosine precision at ~16× less work.cosine
as_of_tslotNoBi-temporal valid-time bound. Applied to candidate cells BEFORE cosine scoring — a cell with no fact whose tslot ≤ as_of_tslot under the scoring band is dropped from the candidate pool (undecidable→drop). When set, the Lance ANN fast-path is bypassed (the index has no signed_at column); brute-force k-NN runs instead so as_of is honoured truthfully.
as_of_signed_atNoBi-temporal transaction-time bound (RFC 3339). Also applied to candidates BEFORE cosine. Same Lance-bypass note as as_of_tslot.
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds important behavioral details: how the 'key' parameter works, default band, scoring modes, and bi-temporal constraints. It honestly notes that as_of_tslot/signed_at bypass the Lance fast-path, showing good transparency. No contradictions with annotations.

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 about 120 words, well-structured with a lead sentence, a 'When to use' paragraph, and technical details. Every sentence adds value; there is no fluff. Front-loaded with purpose, then usage, then parameter details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 6 parameters and no output schema. The description covers key, band, mode, and bi-temporal parameters well, but does not describe the 'k' parameter (though schema provides default) or the output format (list of similar items? scores?). While most context is present, the missing output description and k explanation are gaps given the tool's complexity.

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 description coverage is high (83%). The description adds meaning beyond the schema: explains the inline vector syntax ('inline:[x,y,...]'), clarifies the default band and alternative band, and elaborates on mode behavior and bi-temporal semantics. The 'k' parameter lacks description but schema provides defaults and bounds.

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 states 'k-NN over the corpus by cell embedding or inline vector', clearly specifying the verb (find similar) and resource (corpus). It also provides example user queries ('find places like X'), inherently distinguishing from sibling tools like emem_recall or emem_entity which serve different purposes.

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 explicitly states 'When to use: Call when the user asks...' with concrete examples, giving clear context. However, it does not explicitly state when not to use this tool or mention alternatives among siblings, missing a small opportunity for completeness.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Vortx-AI/emem'

If you have feedback or need assistance with the MCP directory API, please join our Discord server