Skip to main content
Glama
Mikebenisberchmans

QueryForge

by Mikebenisberchmans
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

knowledge_search

Find relevant passages in ingested PDFs via semantic search with reranking, returning scored chunks you can filter by source file to ground answers.

Instructions

Semantic search over the ingested PDF knowledge base.

Pipeline:
  1. Bi-encoder retrieval from ChromaDB (fast ANN search, top_k_retrieve candidates)
  2. Cross-encoder reranking (precise pointwise scoring)
  3. Custom composite metric computation (cosine + rerank + keyword + density)
  4. Returns top_k_return chunks ranked by composite score with full metrics

The composite_score field is the primary relevance signal you should use when
deciding how much to trust each chunk. Scores > 0.7 are highly relevant.

Args:
    query:          Natural-language question or search phrase
    top_k_retrieve: Number of candidates to fetch from the vector DB (default 20)
    top_k_return:   Number of final results to return after reranking (default 5)
    filter_source:  Optional — filter by PDF filename (e.g. "report.pdf")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
top_k_returnNo
filter_sourceNo
top_k_retrieveNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

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?

No annotations, so the description carries the full burden, and it does substantial work: it discloses the retrieval/rerank/composite-score pipeline, how the composite_score should be interpreted (>0.7 highly relevant), and what the return contains. It stops short of describing permissions, latency/cost, or what happens on an empty KB.

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?

Well front-loaded: one-line purpose, then a numbered pipeline, then score interpretation, then args. Slightly verbose and the numbered pipeline is borderline display-oriented, but every section earns its place for a multi-stage tool.

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?

An output schema exists, so return values needn't be enumerated, and the description still adds the key interpretation rule. Combined with full param semantics and pipeline disclosure, it is complete for correct invocation; only cross-sibling routing guidance 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?

Schema description coverage is 0%, so the description must compensate, and it does: it gives meaning, format and defaults for all four args, and explains the retrieve-vs-return relationship (candidate fetch vs final reranked results) plus a concrete filter_source example.

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+resource+scope: 'Semantic search over the ingested PDF knowledge base.' The pipeline detail makes it unambiguous, and it is clearly distinguished from siblings like query_database (SQL) or knowledge_base_info (metadata).

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?

Implied usage is clear (natural-language semantic lookup over PDFs), but there is no explicit when-to-use / when-not guidance and no named alternative such as query_database for structured questions. The description doesn't route the agent among siblings.

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

Deploy Server

Other Tools