Skip to main content
Glama
patsch1
by patsch1

search

Find active knowledge entries using structured filters and relevance-ranked results, with pagination and type counts for filter misses.

Instructions

Search active knowledge entries with structured filters. An empty query lists all matching entries. rank=hybrid (the default) returns both a literal match of the query and every entry containing at least one of its terms, ordered by BM25 relevance; rank=substring matches literally only; rank=bm25 ranks only. An empty hybrid search may return tentative word-form candidates labelled match_kind=word_form; verify their contents before answering. Prefer the default: a multi-word question finds nothing under substring alone. Returns one compact, stably sorted page with total, has_more, and next_offset; use get_entry only for the body or full metadata of a selected result. When a type filter returns total 0, the response adds without_type_filter with the count and types the same query matches once the type restriction is lifted: an entry may be stored under a type other than the one its name suggests, so report those instead of reporting that nothing exists. Relation filters and relation counts describe the state that holds now, or at as_of when one is given.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rankNo
sortNo
typeNo
as_ofNo
limitNo
queryYes
domainNo
offsetNo
explainNo
min_ratingNo
place_kindNo
read_afterNo
related_idNo
experiencedNo
read_beforeNo
product_kindNo
bookmark_kindNo
occurred_afterNo
reading_statusNo
experience_kindNo
interest_statusNo
occurred_beforeNo
attribute_filtersNo
relation_predicateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: empty query lists everything, empty hybrid can return tentative match_kind=word_form candidates that must be verified, results are a single stably sorted page with total/has_more/next_offset, and relation filters reflect current state or as_of. It never states read-only status or what "active" excludes, but the behavioral disclosure is otherwise unusually rich.

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-loaded with purpose, then rank semantics, then pagination and the type-filter fallback, then relation-filter state semantics. Dense but each sentence carries distinct information; the rank explanation is long relative to its weight, which is the only real cost.

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?

For a 24-parameter tool with no annotations, no output schema, and 0% schema coverage, the description does cover the response shape and the highest-stakes semantics (rank, empty query, type fallback). It still leaves most filter parameters and the sort/limit/pagination controls unexplained, so it is not fully complete for the surface it exposes.

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

Parameters3/5

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

Schema description coverage is 0% across 24 parameters, and the description compensates only partially: rank's three modes and default, empty-query behavior, type-filter fallback, relation filters, and as_of are explained in depth. The remaining filters (limit, offset, sort, explain, domain, min_rating, place_kind, product_kind, bookmark_kind, reading_status, experience_kind, interest_status, occurred/read date bounds, related_id, attribute_filters) get no explanation, leaving much of the surface undocumented in both schema and description.

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 ("Search active knowledge entries") and narrows scope with "active" and "structured filters", which separates it from trash/restore siblings. It also explicitly routes body/metadata retrieval to get_entry, so an agent can distinguish it from find_candidates, retrieve, and relations without opening another schema.

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?

Gives explicit when-to-use guidance: prefer the default hybrid because "a multi-word question finds nothing under substring alone", use get_entry only for the body of a selected result, and when a type filter returns total 0 report without_type_filter rather than declaring nothing exists. That is when/when-not/alternative coverage in one place.

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