Skip to main content
Glama
norrietaylor

io.github.norrietaylor/distillery-mcp

Official
by norrietaylor

distillery_list

List and filter knowledge entries by type, author, tags, status, and more, with pagination and newest-first ordering. Use when you need to browse entries without a semantic search query.

Instructions

List knowledge entries with optional filters and pagination (newest first).

USE WHEN: browsing or filtering entries without a semantic query. Use distillery_search instead when you have a natural-language question.

By default, only entries with status in (active, pending_review) are returned — archived entries are hidden. Pass status="archived" to list only archived entries, status="any" to include every status, or include_archived=true to add archived entries to the default view.

PARAMS:

  • entry_type (str | list[str], optional): Filter by type, or a list of types matched with OR (e.g. ["session", "reference"]) — pair with group_by to aggregate across several types in one call. Valid: [session, bookmark, minutes, meeting, reference, idea, inbox, github, person, project, digest, feed].

  • author (str, optional): Filter by author.

  • project (str, optional): Filter by project scope.

  • tags (list[str], optional): Filter by tags (AND match).

  • status (str, optional): Filter by status. Valid: [active, pending_review, archived, any]. Default hides archived; use "any" to include all.

  • verification (str, optional): Filter by verification. Valid: [unverified, testing, verified].

  • source (str, optional): Filter by origin. Valid: [claude-code, manual, import, inference, documentation, external]. As a convenience, a URL-shaped value (starting with "http://" or "https://") is aliased to feed_url so source="https://hnrss.org/frontpage" matches feed items ingested from that source (same semantics as passing feed_url=...).

  • session_id (str, optional): Filter by session identifier.

  • date_from (str, optional): ISO 8601 lower bound on created_at.

  • date_to (str, optional): ISO 8601 upper bound on created_at.

  • limit (int, optional, default=20): Max entries to return (1-500).

  • offset (int, optional, default=0): Pagination offset.

  • tag_prefix (str, optional): Filter tags by namespace prefix.

  • output_mode (str, optional, default="summary"): Response shape. Valid: [full, summary, ids, review]. "summary" returns id/title/tags/project/ author/created_at plus a ~200-char content_preview (default — keeps responses small to conserve context). "full" returns entire content body. "ids" returns id/entry_type/created_at only. "review" filters to pending_review and enriches with confidence/classification_reasoning.

  • content_max_length (int, optional): Truncate content to N chars (full mode only).

  • stale_days (int, optional): Restrict to entries not accessed in N days (>= 1).

  • group_by (str, optional): Return grouped counts instead of entries. Valid: [entry_type, status, author, project, source, tags]. Mutually exclusive with output="stats".

  • output (str, optional): Set to "stats" for aggregate statistics. Mutually exclusive with group_by.

  • feed_url (str, optional): Filter to entries ingested from a registered feed source URL (matches metadata.source_url written by the poller). Use this to retrieve all items polled from e.g. "https://hnrss.org/frontpage".

  • include_archived (bool, optional, default=False): Include archived entries in the default view (same effect as status="any" when status is unset).

  • published_after (str, optional): ISO 8601 inclusive lower bound on metadata.published_at (the feed-item publication timestamp written by the poller). Use this to bound the /radar candidate set by the digest window.

  • published_before (str, optional): ISO 8601 inclusive upper bound on metadata.published_at.

  • include_evergreen (bool, optional, default=False): When False (default) and published_after/published_before is set, also drops entries flagged metadata.backfill=true so first-poll backfill items don't surface as "new intelligence". Set to True to surface older / evergreen items explicitly. See issue #444.

  • structural (list[str], optional): Surface entries with specific graph anomalies relative to entry_relations. Accepted values: ["orphans"] — entries that do not appear as either endpoint of any relation row. Unknown values yield INVALID_PARAMS. Combines (AND) with every other filter (project, tags, status, date range, stale_days, etc.) — orphans are first restricted by those filters, then the no-relations predicate is applied.

RETURNS (success): { entries: list, count: int, total_count: int, limit: int, offset: int, output_mode: str } — when structural is set, the payload additionally includes structural_filter (comma-joined applied filters, e.g. "orphans"). Existing fields are unchanged. RETURNS (error): { error: true, code: "INVALID_PARAMS" | "INTERNAL", message: "..." }

RELATED: distillery_search (for semantic search), distillery_status (for lightweight server health/metadata)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNo
limitNo
authorNo
offsetNo
outputNo
sourceNo
statusNo
date_toNo
projectNo
feed_urlNo
group_byNo
date_fromNo
entry_typeNo
session_idNo
stale_daysNo
structuralNo
tag_prefixNo
output_modeNosummary
verificationNo
published_afterNo
include_archivedNo
published_beforeNo
include_evergreenNo
content_max_lengthNo
Behavior5/5

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

Since no annotations are provided, the description carries the full burden. It discloses default status filtering, pagination ordering ('newest first'), response modes (summary/full/ids/review), content preview behavior, source-to-feed_url aliasing, mutual exclusions (group_by/output='stats'), stale_days semantics, include_evergreen backfill handling, and structural filter behavior. It also details return fields and error codes. This is exhaustive and beyond what any annotation could provide.

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 necessary given 24 parameters. It is well-structured with sections (PARAMS, RETURNS, RELATED) and front-loads the core purpose and usage. Some redundancy exists (status behavior repeated in the intro and status parameter, include_archived explanation overlaps), but it remains efficient and each parameter earns its place. A minor trim would push it to 5.

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 highly complex tool with no output schema and no annotations, the description is exceptionally complete. It explains return shape, error codes, mutual exclusions, edge cases (e.g., include_evergreen, structural orphan behavior), and references related tools. An agent would have everything needed to invoke it correctly.

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 must compensate for all 24 parameters. It does so thoroughly: each parameter explains its purpose, valid values (e.g., entry_type enums, status options, source origins), defaults, and special behaviors (e.g., source URL alias to feed_url, structural filter combination, content_max_length truncation). This adds substantial meaning far beyond the bare schema types.

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 a specific verb and resource: 'List knowledge entries with optional filters and pagination (newest first).' It immediately distinguishes from distillery_search by stating it is for browsing/filtering without a semantic query, and it names the alternative explicitly. The purpose is unambiguous and differentiates from 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?

The description explicitly states 'USE WHEN: browsing or filtering entries without a semantic query' and directs to 'Use distillery_search instead when you have a natural-language question.' It also explains the default status behavior (active/pending_review with archived hidden) and how to override it, giving clear when-to/not-to guidance.

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