Skip to main content
Glama
norrietaylor

io.github.norrietaylor/distillery-mcp

Official
by norrietaylor

distillery_relations

Manage typed relations linking knowledge entries—add, get, remove, traverse multi-hop paths, compute graph metrics, or promote entities from tags. Solve graph analysis and linking needs with actions like bridges, communities, and orphans.

Instructions

Manage typed relations between knowledge entries.

USE WHEN: linking entries together (e.g. marking one as blocking another, citing a reference, or flagging duplicates), walking the relation graph from a seed entry to surface multi-hop neighbours, or computing graph metrics (bridges, communities) on the relations subgraph.

PARAMS:

  • action (str, required): Operation. Valid: [add, get, remove, traverse, metrics, promote_entities].

  • from_id (str, required for add): Source entry UUID.

  • to_id (str, required for add): Target entry UUID.

  • relation_type (str, required for add, optional for get/traverse): Relation type. Valid: [link, corrects, supersedes, related, blocks, depends_on, citation, duplicate, merge_source, sync_source, mentions, chunk].

  • weight (float, optional for add): Edge strength (e.g. interest/engagement magnitude). On a re-assert of an existing edge, supplied attributes are upserted.

  • valid_at / invalid_at (str ISO 8601, optional for add): Bi-temporal validity window — when the relationship became / stopped being true (invalid_at null = current).

  • metadata (object, optional for add): Arbitrary per-edge attributes (JSON).

  • entry_id (str, required for get/traverse, required for metrics scope='ego'): Entry UUID to query relations for (BFS root for traverse / ego-graph).

  • direction (str, optional for get/traverse, default="both"): Filter direction. Valid: [outgoing, incoming, both].

  • relation_id (str, required for remove): UUID of the relation to delete.

  • hops (int, optional for traverse, default=2): BFS depth, capped at [1, 3].

  • metric (str, required for metrics): Graph metric to compute. Valid: [bridges, communities, constraint, link_prediction, orphans]. Requires the [graph] optional extra.

  • scope (str, optional for metrics, default="global"): Subgraph scope. Valid: [global, ego]. "ego" requires entry_id.

  • limit (int, optional for metrics, default=10): top-k results. bridges = entries by betweenness centrality; communities = K largest communities; constraint = entries by lowest Burt constraint (strongest structural-hole brokers); link_prediction = top predicted edges by Adamic-Adar (pass entry_id to score adjacencies for one entry); orphans = sample (<=50) of entry IDs absent from the relations graph (unlinked entries — feeds a linking / gap-scan pass).

  • project / tags / date_from / date_to (optional, metrics global scope): restrict the entries whose relations participate in the graph.

RETURNS (success): { relation_id: str, from_id: str, to_id: str, relation_type: str, weight: float | null, valid_at: str | null, invalid_at: str | null, metadata: object | null } (add) or { entry_id: str, relations: list, count: int } (get) or { relation_id: str, removed: bool } (remove) or { action: "traverse", root: str, hops: int, direction: str, relation_type: str | null, nodes: [{id: str, depth: int}], edges: [{from_id, to_id, relation_type}], node_count: int, edge_count: int } (traverse) or { action: "metrics", metric: str, scope: str, node_count: int, edge_count: int, total_entries: int, graph_node_count: int, orphan_rate: float, results: list, count: int, computed_at: str, cache_hit: bool } (metrics). orphan_rate = 1 - graph_node_count/total_entries (graph-health signal; 0.0 when total_entries is 0). Or { action: "promote_entities", entities_created: int, entities_reused: int, mentions_created: int, threshold: int } (promote_entities). Scans entity/* and tech/* tags and promotes any canonical tag meeting the configured tags.entity_promotion_threshold to an ENTITY entry node, linking each tagged entry with a mentions edge. Idempotent. RETURNS (error): { error: true, code: "NOT_FOUND" | "INVALID_PARAMS" | "INTERNAL", message: "..." }

RELATED: distillery_correct (creates 'corrects' relations automatically), distillery_find_similar (to discover related entries)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hopsNo
tagsNo
limitNo
scopeNoglobal
to_idNo
actionYes
metricNo
weightNo
date_toNo
from_idNo
projectNo
entry_idNo
metadataNo
valid_atNo
date_fromNo
directionNoboth
invalid_atNo
relation_idNo
relation_typeNo
Behavior5/5

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

Given there are no annotations, the description carries the full burden of behavioral disclosure. It details side effects (upsert on re-assert), idempotency of promote_entities, error codes (NOT_FOUND, INVALID_PARAMS, INTERNAL), return structures for every action, and even explains the orphan_rate formula. No contradictions with annotations (none provided).

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?

The description is long but well-structured with sections (USE WHEN, PARAMS, RETURNS, ERROR, RELATED). It is front-loaded with the core purpose and then provides exhaustive details. While some verbosity exists (e.g., repeating default values that are already in the schema), the density is justified given the tool's complexity (6 actions, 19 params). A 5 would require even tighter prose; a 3 would be too short. 4 reflects a strong but not perfect balance.

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 19 parameters, 6 actions, no schema descriptions, and no output schema, the description is comprehensive. It documents all input parameters, return shapes for every action, error handling, and even extra requirements (e.g., metrics requiring the [graph] extra). Nothing an agent needs to correctly invoke the tool is missing.

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?

The schema has 0% description coverage, so the description must explain every parameter. It does: each parameter's type, required condition, valid values (e.g., action values, relation_type enum), defaults, and semantic meaning (e.g., weight as edge strength, valid_at/invalid_at bi-temporal window, metric behaviors like betweenness vs. Adamic-Adar). This is a textbook example of description compensating for schema gaps.

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 'Manage typed relations between knowledge entries.' This is a specific verb and resource. It then enumerates concrete use cases (linking entries, walking the graph, computing metrics) and names two sibling tools (distillery_correct, distillery_find_similar) that it is not, distinguishing it clearly from the related tools.

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?

The 'USE WHEN' section explicitly tells the agent when to employ this tool (linking, traversing, metrics) and the 'RELATED' section points to alternatives: distillery_correct for auto-creating 'corrects' relations and distillery_find_similar for discovering related entries. This is explicit when/when-not guidance, leaving no ambiguity.

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