Skip to main content
Glama
probityai

agent-evidence-mcp

Official
by probityai

Explain one conformance vector

explain_vector
Read-onlyIdempotent

Inspect a single conformance vector: returns its manifest entry, tested conditions, and input bytes for offline replay verification.

Instructions

Return one vector: its manifest entry, the conditions it tests, and its input bytes.

Input Schema

NameRequiredDescriptionDefault
corpusNovectors
vector_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the payload composition (manifest entry, conditions, input bytes), but says nothing about behavior on a missing vector_id or how the default corpus is applied.

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?

A single front-loaded sentence with no filler; the key object ('one vector') comes first and the three returned components are listed inline. It is efficient, though the terseness leaves the gaps noted elsewhere unaddressed.

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

Completeness2/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 spelled out, yet the 0%-coverage input schema is not compensated for: neither corpus nor vector_id is explained, and there is no error or not-found behavior. For a lookup tool with an undocumented scoping parameter, the description does too little.

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% and the description never explains either parameter. The 'corpus' parameter, which defaults to 'vectors' and scopes the lookup, is entirely undocumented in both places — a real gap for an agent that must know whether to pass it.

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

Purpose4/5

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

States a specific verb ('Return') and resource ('one vector') and enumerates what comes back: the manifest entry, the tested conditions, and the input bytes. It is distinguishable from list_vector_corpora and run_vectors by its single-vector scope, though it never names those siblings explicitly.

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

Usage Guidelines2/5

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

No when-to-use guidance, no exclusions, and no mention of the alternatives (list_vector_corpora for enumeration, run_vectors for execution). 'One vector' implies a single-item lookup, but the agent must infer why it would choose this over the sibling tools.

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