Skip to main content
Glama

kosh_verify

Verify a question against local temporal and causal evidence to get a JSON report with supporting facts, contradictions, missing evidence, and abstention states.

Instructions

Verify a question against local temporal/causal evidence.

This is read-only. The returned JSON report can include supporting facts, causal paths, contradictions, inferred-but-not-discovered relationships, missing evidence, stability information, and an explicit abstention state.

It does not consult the internet, seed demo data, write or mutate memory, export private context, or make an imported source trustworthy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNo
queryYes
dialecticNo
temporal_contextNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.3

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of disclosing safety and behavioral traits. The description does explicitly state 'read-only' and lists what it does not do (internet, mutation, export private context). However, it does not explain the meaning of the return fields (e.g., how contradictions are determined, what 'stability information' means) or whether the tool has side effects like noise. It is a read-only operation, but the description could be clearer on how the verification is performed or what the output format implies. The contradiction flag is false, but the lack of detail on behavioral specifics (e.g., whether it modifies any state in the analysis process) is a gap.

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?

The description is concise and structured as a single paragraph, with the main purpose in the first sentence, followed by a list of what the output can include)Skip. The exclusions are listed in a separate sentence, which is efficient. It is front-loaded with the core purpose and then provides supporting details. No excessive fluff, but it could be slightly more broken down for skimmability; still, it's well-organized for the content provided.

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?

The tool has no output schema, no annotations, and parameters are undocumented. The description provides an overview of the return fields (supporting facts, causal paths, etc.) but lacks detail on how the agent should interpret them, what 'abstention state' is, or how to handle the output. It also doesn't clarify the expected behavior of parameters like 'depth' or 'dialectic'. Given the complexity of temporal/causal verification, the description is insufficient for an agent to use the tool correctly without trial and error. The complexity is moderate, but the lack of parameter details and output schema leaves gaps.

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%, meaning the description does not add any meaning to the parameters beyond their names. The description does not explain what 'depth', 'dialectic', or 'temporal_context' mean or how they affect the verification. The parameter names and defaults are present, but no additional context is given. This is a significant gap because with 4 parameters, the agent needs to understand what each does, especially 'dialectic' which is non-trivial. The description is completely silent, so it fails to compensate for the lack of schema hints.

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?

The description clearly states that the tool verifies a question against local temporal/causal evidence)Skip. The verb 'Verify' and resource 'question against local temporal/causal evidence' are specific. It distinguishes itself from siblings by emphasizing local, temporal/causal, and read-only nature, which aligns with the sibling names like trusted_memory_recall and company_memory_search that likely focus on retrieval or proposal, not verification. However, it doesn't explicitly compare with siblings, so a 4 is warranted.

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 the tool is for verification, not for retrieving memories or proposing changes, as suggested by 'read-only' and the focus on evidence. It lists exclusions ('does not consult the internet, seed demo data, write or mutate memory...') which are useful boundary conditions confirming it is for read-only verification. However, it does not explicitly state when to use this tool versus a specific sibling like search_memory or reasoning_query, leaving the agent to infer from the generic description.

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