Skip to main content
Glama
dave1362

RCA-MCP Connector

rca_analysis_query_results

Read-onlyIdempotent

Filter stored RCA results by model family, confidence, time range, or tags to find relevant outcomes without loading full records. Returns lightweight index entries for fast scanning.

Instructions

Query stored RCA results by model family, confidence threshold, time range, or tags — without loading every full result record. Use this instead of rca_analysis_list_results whenever you need to filter (e.g. "only high-confidence Granger results from this week"); use rca_analysis_list_results for a plain unfiltered listing instead. Returns lightweight index entries, not full result bodies -- follow up with rca_analysis_get_result for the complete content of any one.

Args: params (QueryResultsInput): - model_family: exact family name, e.g. "granger_causality" (omit for all families) - min_confidence: 0.0-1.0, only results at or above this - after_ts: ISO timestamp, only results executed at or after this - tags: only results matching any of these tags - limit, offset: pagination, 1-100 per page

Returns: str: JSON {total, results: [index entries], has_more}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.1.15
    • addedInput schema / $defs / QueryResultsInput / properties / client_id / description
      Added value: +"Client namespace ID"
    • addedInput schema / $defs / QueryResultsInput / properties / token / description
      Added value: +"API key to authenticate this request"
  2. Changed3 schema fields changedv4.1.14
    • addedInput schema / $defs / QueryResultsInput / properties / limit / description
      Added value: +"Page size, 1-100"
    • addedInput schema / $defs / QueryResultsInput / properties / min_confidence / description
      Added value: +"Only return results with confidence_overall at or above this, 0.0-1.0 (default 0.0 = no filter)"
    • addedInput schema / $defs / QueryResultsInput / properties / offset / description
      Added value: +"Number of matching results to skip, for paging"
  3. First observedv4.1.13

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark readOnly/idempotent/non-destructive, and the description adds meaningful behavior: it does not load every full result, it returns lightweight index entries, and it returns a JSON structure with total/results/has_more. Pagination semantics are also disclosed. No contradiction with annotations.

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?

Well-structured and front-loaded: purpose first, alternative routing second, return behavior third, then concise parameter bullets and return format. Every sentence serves a purpose and the length is justified by the richness of the guidance.

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

Completeness5/5

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

Complete for a read-only filtered query tool. It explains what it returns, how pagination works, which sibling to use for unfiltered listing, and how to get full result bodies. Required auth is captured in the schema, so nothing critical is missing.

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

Parameters4/5

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

The description adds valuable semantic detail beyond the schema: examples for model_family, confidence ranges, ISO timestamp format, tag matching behavior, and pagination limits. It omits the required token and client_id from the Args summary, but the input schema fully documents those, so an agent can still invoke the tool correctly.

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 ('Query') and resource ('stored RCA results') with explicit filter dimensions (model family, confidence, time, tags) and the lightweight-index behavior. Explicitly distinguishes itself from the sibling rca_analysis_list_results by naming the alternative, so an agent can tell them apart without inspecting the 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?

Explicitly states when to use this tool instead of rca_analysis_list_results ('whenever you need to filter') and directs plain unfiltered listings to the sibling. It also tells the agent to follow up with rca_analysis_get_result for full content when needed, providing clear routing guidance.

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