Skip to main content
Glama

search_similar

Find past defect analyses with similar error signatures, root causes, or components using hybrid semantic and BM25 keyword matching. Narrow results by product, verdict, component, or error type to speed up triage.

Instructions

Hybrid semantic + keyword search for similar past defects in the KB.

Combines dense vector similarity with BM25 keyword matching via Reciprocal Rank Fusion. Use this at the start of a new triage to find historical defects with similar error signatures, root causes, or affected components. Optional filters narrow results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
top_kNo
productNo
verdictNo
componentNo
error_typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses the hybrid retrieval mechanism (dense vectors + BM25 via Reciprocal Rank Fusion) and that optional filters narrow results. It does not describe output shape or limits, but the non-mutating search behavior is clear and well-specified.

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?

Three sentences with no filler. The first sentence summarizes the tool, the second explains the mechanism, and the third gives usage guidance. It is front-loaded and every sentence earns its place.

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?

The description adequately covers what the tool does, when to use it, and how ranking works. However, with no output schema and no parameter descriptions, it leaves top_k semantics, filter value expectations, and return format implicit, requiring the agent to infer important details.

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

Parameters2/5

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

Schema description coverage is 0%, yet the description only mentions 'Optional filters narrow results' without explaining query, top_k, product, verdict, component, or error_type. Parameter names are somewhat self-explanatory, but the description fails to compensate for the complete lack of schema-level documentation.

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 states a specific verb and resource: 'search for similar past defects in the KB.' It clearly differentiates itself from the sibling CRUD and stats tools by describing a hybrid semantic + keyword retrieval operation.

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 explicitly says when to use it: 'Use this at the start of a new triage to find historical defects with similar error signatures, root causes, or affected components.' It provides clear context, though it does not explicitly state when not to use it or name alternatives.

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