Skip to main content
Glama
norrietaylor

io.github.norrietaylor/distillery-mcp

Official
by norrietaylor

distillery_find_similar

Find stored entries similar to input text or an anchor entry to detect duplicates, conflicts, and hidden relations, with options for batch processing and relation actions.

Instructions

Find stored entries similar to the given text (cosine similarity).

USE WHEN: checking for duplicates or conflicts before storing, finding entries related to arbitrary text, or surfacing hidden connections to a known entry (entries that are similar but not yet linked via relations). Supports progressive disclosure modes.

PARAMS:

  • content (str, optional): Text to compare against stored entries. Required unless source_entry_id is provided. When both are set, content wins as the similarity probe.

  • threshold (float, optional, default=0.8): Cosine similarity cutoff (0-1).

  • limit (int, optional, default=10): Max results (1-200).

  • dedup_action (bool, optional, default=false): When true, includes dedup check with recommended action (create/skip/merge/link).

  • conflict_check (bool, optional, default=false): When true, includes conflict candidates with LLM evaluation prompts.

  • llm_responses (list[dict], optional): With conflict_check=true, evaluates LLM conflict verdicts. Each item: { entry_id: str, is_conflict: bool, reasoning: str }.

  • source_entry_id (str, optional): Anchor entry whose content is used as the similarity probe when content is omitted, and whose id is self-excluded from results. Required when exclude_linked=true. When set without content/dedup/conflict/accept_action, reuses the entry's STORED embedding (no re-embed, no embedding-budget spend).

  • source_entry_ids (list[str], optional): BATCH mode. Up to 50 seed ids. Reuses each seed's STORED embedding (no re-embed, no embedding-budget spend) and runs all similarity queries in ONE round-trip. Standalone — cannot be combined with content, source_entry_id, dedup_action, conflict_check, accept_action, or llm_responses (INVALID_PARAMS). Honours threshold, limit, and exclude_linked per seed; each seed always self-excludes.

  • exclude_linked (bool, optional, default=false): When true, filters out entries already linked to source_entry_id (or, in batch mode, to each seed) via entry_relations (any direction, any relation_type). Surfaces hidden connections.

  • accept_action (str, optional): When set, persists an entry_relations row from source_entry_id to each result above threshold. Valid: ['link' → related, 'merge' → merge_source, 'duplicate' → duplicate]. Requires source_entry_id. Idempotent via the unique (from_id, to_id, relation_type) index.

RETURNS (success, single/content): { results: [{ score: float, entry: {...} }], count: int, threshold: float, dedup?: { action: str, similar_entries: list }, conflict_candidates?: list, conflict_evaluation?: dict, excluded_linked_count?: int } Note: excluded_linked_count is present whenever source_entry_id is set or exclude_linked=true. It counts both linked-source exclusions (when exclude_linked=true) and the self-exclusion of source_entry_id itself (when source_entry_id == candidate); a non-zero value is therefore possible even with exclude_linked=false. RETURNS (success, batch / source_entry_ids): { results_by_seed: { "": { results: [{ score: float, entry: {...} }], count: int, excluded_count: int } }, seed_count: int, threshold: float } A seed with no stored embedding maps to an empty results list (not an error). excluded_count is best-effort (reported as 0 in batch mode). RETURNS (error): { error: true, code: "INVALID_PARAMS" | "NOT_FOUND" | "BUDGET_EXCEEDED" | "INTERNAL", message: "..." }

RELATED: distillery_store (stores with automatic dedup/conflict checks), distillery_search (for natural-language queries), distillery_relations (to inspect existing links between entries)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
contentNo
thresholdNo
dedup_actionNo
accept_actionNo
llm_responsesNo
conflict_checkNo
exclude_linkedNo
source_entry_idNo
source_entry_idsNo
Behavior5/5

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

No annotations are provided, so the description carries the full burden — and it does so comprehensively. It discloses embedding-budget implications ('reuses the entry's STORED embedding (no re-embed, no embedding-budget spend)'), idempotency via the unique (from_id, to_id, relation_type) index, the nuanced excluded_linked_count semantics (counts both linked-source exclusions and self-exclusion), batch-mode edge cases (seed with no embedding maps to empty results, excluded_count best-effort reported as 0), and the full error-code surface. Genuinely rich behavioral context beyond any structural field.

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 long, but appropriately so for a 10-parameter, three-return-mode tool at 0% schema coverage. It is disciplined in structure: front-loaded purpose, then USE WHEN, PARAMS, RETURNS (single/batch/error), and RELATED. Each sentence carries information — batch embedding reuse, idempotency, excluded_count semantics — with no filler or repetition. The length earns its place given the tool's complexity.

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?

For a tool with 10 parameters, three distinct return shapes, a standalone batch mode, idempotency, and embedding-budget side effects — with zero schema descriptions and no output schema — the description is remarkably complete. It documents every parameter, every return shape including the batch variant and error codes, plus edge cases (missing embeddings, best-effort counts). The minor mention of 'progressive disclosure modes' without elaboration is the only slight gap, and it does not undermine completeness for a tool this complex.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates for every one of the 10 parameters. Each param gets purpose and constraints: content's precedence rule ('When both are set, content wins'), threshold's cutoff range (0-1), limit's bounds (1-200), the batch-mode exclusivity rule for source_entry_ids ('cannot be combined... INVALID_PARAMS'), and accept_action's valid enum plus idempotency note. At zero schema coverage, this is maximal compensation — no parameter is left without semantic grounding.

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?

Opens with a specific verb+resource statement, 'Find stored entries similar to the given text (cosine similarity),' and immediately distinguishes itself from siblings via the USE WHEN section ('checking for duplicates or conflicts before storing, finding entries related to arbitrary text, or surfacing hidden connections'). The RELATED block explicitly contrasts against distillery_search (natural-language) and distillery_relations (inspecting links), leaving no ambiguity about what this tool is versus its siblings.

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?

Provides an explicit USE WHEN list with concrete selection scenarios (duplicate/conflict checking before storing, relating arbitrary text, surfacing hidden connections), and names alternatives in RELATED: distillery_store for storing with automatic checks, distillery_search for natural-language queries, distillery_relations for inspecting existing links. Both positive selection conditions and exclusions are articulated; an agent can route correctly without inference.

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/norrietaylor/distillery'

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