Skip to main content
Glama
Sign In

Ground Truth - Fresh Evidence for AI Agents

by io.github.anish632
OverviewDiscussionsAdmin

Claim Support Check

verify_claim
Read-onlyIdempotent

Verify a factual claim against specific public evidence URLs before an agent repeats it or acts on it. The tool checks whether supplied keywords appear in each fetched source and reports per-source evidence. It does not perform open-ended search, semantic contradiction analysis, or prove a claim true when a page is silent; choose direct evidence URLs and interpret the result as a support signal. Fetched pages are cached for 5 minutes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "claim": "<claim>",
      "evidence_urls": "<evidence_urls>",
      "keywords": "<keywords>"
    },
    "name": "verify_claim"
  }
}

Input Schema

NameRequiredDescriptionDefault
claimYesPlain-language claim to verify, for example 'AWS Business support includes 24/7 phone support'.
keywordsYesKeywords or short phrases that should appear on supporting pages. Matching is case-insensitive substring matching, so choose phrases that are likely to appear verbatim.
evidence_urlsYesOne to ten public documentation, pricing, policy, or support URLs that are likely to contain direct evidence for the claim.

Output Schema

NameRequiredDescriptionDefault
claimYesClaim that was evaluated.
sourcesYesPer-source evidence results.
verdictYesAggregate verdict across all supplied sources.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses the 5-minute caching behavior, case-insensitive substring matching, and the fact that it does not prove a claim true when a page is silent. These details add meaningful context.

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?

The description is concise yet information-dense, front-loading the purpose and covering mechanism, limitations, and caching in a few sentences. No filler or redundancy.

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?

Given the rich annotations, output schema, and fully documented parameters, the description covers the tool's behavior, limitations, and usage context comprehensively. It explains what the tool returns (per-source evidence) and how to interpret it.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description does not add significant parameter-specific semantics beyond what the schema already provides; it reinforces purpose but doesn't explain parameter formats or edge cases.

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 opens with a specific verb and resource: 'Verify a factual claim against specific public evidence URLs.' It clearly states the tool's mechanism (checks keyword appearance) and explicitly contrasts with open-ended search or semantic analysis, distinguishing it from sibling tools like test_hypothesis.

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?

The description explains when to use the tool: 'before an agent repeats it or acts on it.' It explicitly states limitations ('does not perform open-ended search, semantic contradiction analysis') and provides guidance on choosing direct evidence URLs and interpreting results as support signals.

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

All Ground Truth - Fresh Evidence for AI Agents toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources