Skip to main content
Glama

Search reviews and known subjects

search
Read-onlyIdempotent

Search reviews plus matching reviewed or unreviewed subjects. Search is lexical rather than semantic: for an ordinary question try one discriminating keyword at a time, then exact subject-name follow-ups and fetch every returned review. Continue with next_cursor until has_more is false before claiming exhaustive retrieval. Never merge records by display name: group and compare using subject_id and subject_type because unrelated subjects may share a name. Known subjects include immediate subject-to-subject connections so a location, organisation, variant or sibling discovered earlier can inform recommendations without being misrepresented as reviewed. For a location-based recommendation, do not stop when the target-town query has no direct result: also search the relevant subject type without a text query, follow reviewed subjects to parent organisations, and inspect each parent's official branch directory for the requested location before concluding there is no useful connection. Search returns collection_coverage on collection subjects and connected parents. Only coverage_status=complete permits a conclusion that a location or member is absent; partial or unknown coverage must be reported as uncertainty. Routine chain expansion does not require user confirmation. Search is lexical rather than semantic. For an ordinary user question, try one discriminating keyword at a time and retry with a subject-type-only search when necessary. A keyword hit is only a discovery step: search each candidate's exact subject name, then fetch every returned review before answering so reviews that omit the original keyword are not missed. Retrieval is deliberately softer than canonical naming. Search using the user's wording first, then try known aliases, canonical type names and useful broader/related types when needed. A search miss for one label is not evidence that the underlying subject or concept is absent. Stable IDs, not preferred labels, determine identity. Use bounded best-first traversal: inspect only the current level, rank a small set of plausible branches, follow the strongest while retaining fallback candidates, and backtrack if that branch gives an inadequate classification or retrieval result. Stop at the most specific adequate existing type or when bounded evidence justifies a new type; do not enumerate the complete taxonomy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryNo
cursorNoOpaque next_cursor returned by the preceding identical search.
subject_typeNo
include_relatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is handled. Beyond that the description adds genuinely useful behavior: pagination via next_cursor until has_more is false, that only coverage_status=complete permits an absence conclusion, and that collection_coverage is returned for collection subjects. It does not describe result shape in detail (no output schema exists), which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is heavily redundant: 'Search is lexical rather than semantic' appears twice, and the refresh-keyword-then-follow-up guidance is repeated nearly verbatim in two separate blocks. Much of the taxonomy-traversal advice (bounded best-first traversal, stopping at the most specific adequate type) reads like it belongs to a different tool. The valuable routing content is front-loaded, but the bloat significantly hurts scanability.

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 tool with no output schema and 20% parameter coverage, the description does cover a lot of ground: lexical vs semantic behavior, pagination, coverage semantics, identity via subject_id/subject_type, and search strategy. However, the redundancy pushes some genuinely needed detail (limit behavior, when include_related should be false) out of view, leaving gaps an agent would notice on a careful read.

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 only 20% (only cursor is documented), so the description must carry the load. It does add real meaning for query (lexical, one discriminating keyword at a time), subject_type (type-only searches, canonical/alias/broader types), and implicitly include_related via 'known subjects include immediate subject-to-subject connections'. But limit and cursor semantics beyond what the schema states are unaddressed, so compensation is partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence does state a specific verb and resource: 'Search reviews plus matching reviewed or unreviewed subjects.' However, that core statement is immediately buried under procedural workflow text, and nothing in it cleanly distinguishes this tool from siblings such as fetch, vocabulary_index, or resolve_subject. An agent can extract the purpose but must dig through ~350 words of tangents to confirm it.

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 is unusually explicit about how to conduct a search: start with the user's wording, retry with subject-type-only when a keyword fails, follow up with exact subject names, paginate until has_more is false, and use bounded best-first traversal with backtracking. It also names a fallback strategy (search the relevant subject type without a text query, inspect parent branch directories). It stops short of naming sibling tools as alternatives, so it is not a full 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.