Skip to main content
Glama

quorum

by io.github.Godzilla-lab

search_evidence

Read-onlyIdempotent

Search the retained corpus for what people actually said about a product or topic. Returns how many independent records exist, across how many channels, whether that clears the corroboration threshold, and the loudest few quotes with their receipt ids. Costs nothing and touches no network.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
afterNoOptional. ISO date (2026-01-31): only records their authors wrote on or after it. Undated records sit inside no window.
queryYesWhat to look for: "sizing", "battery life", "runs small".
beforeNoOptional. ISO date: only records written on or before it.
phraseNoOptional. Match the words as one ordered phrase, no any word fallback. Build phrases from content words.
sourcesNoOptional. Only these sources (reddit, appstore, sec-edgar...).
categoryNoOptional. Narrow to one product category.
minChannelsNoOptional. Demand at least this many distinct channels for a finding verdict. Can only demote.
sourceClassesNoOptional. Filter by what kind of speaker: consumer_voice (reddit, reviews...), practitioner (github...), institutional (regulators, filings).
excludeSourcesNoOptional. Drop these sources, e.g. ["sec-edgar", "cpsc"] to drop the institutional records from a consumer question.

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description adds valuable behavioral context: it explicitly states the tool 'Costs nothing and touches no network,' and describes what it returns (counts, channels, threshold, quotes with receipt IDs). This goes beyond the structured annotations by detailing the output scope and operational characteristics.

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 a single, dense sentence that front-loads the core purpose ('Search the retained corpus') and packs in the return details and operational notes without fluff. Every clause adds value, and the structure is logical — purpose, then result summary, then cost/network note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 9 parameters but no output schema, the description covers the key return elements (counts, channels, threshold, quotes with receipt IDs) and notes that it's free and offline. It doesn't explain the corroboration threshold in detail, but the schema handles parameter specifics. The description is sufficiently complete for an agent to understand what to expect when calling the tool.

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 100%, so all parameters are documented in the schema itself. The description does not add extra meaning to individual parameters; it refers to the general search behavior but not to specific parameters. Given the full schema coverage, the baseline of 3 is appropriate.

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 starts with a specific verb and resource: 'Search the retained corpus for what people actually said about a product or topic.' It clearly states the tool's action and scope, and distinguishes it from siblings by describing its unique return (counts, channels, threshold, quotes with receipt ids) — something none of the sibling tools do.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to search for evidence from the retained corpus) but does not explicitly compare to alternatives or state when not to use it. No exclusions or 'use instead' guidance is provided, leaving the agent to infer context from the tool's name and purpose.

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

All quorum toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool maps to a clearly distinct operation: checking category cache/warmth, comparing ad formats, resolving receipt IDs, and searching the evidence corpus. Even though search_evidence and get_receipt both return evidence, one is query-based and the other is a direct ID lookup, so there is no real ambiguity.

Naming Consistency4/5

Three tools follow a clean verb_noun pattern: compare_formats, get_receipt, search_evidence. category_warmth is the one outlier as a noun phrase, but it is still descriptive and fits the domain's 'warmth' concept, so the inconsistency is minor.

Tool Count5/5

Four tools is a compact but well-scoped set for an evidence-retrieval/corroboration server. Each tool earns its place: orient, search, compare, and verify. There is no redundant bulk or missing essential operation within the stated purpose.

Completeness5/5

The read-only evidence domain is covered end to end: category_warmth provides orientation, search_evidence returns corpus results with corroboration status, compare_formats delivers the comparison verdict, and get_receipt lets agents verify the underlying records. The workflow has no obvious dead ends.

Resources