Skip to main content
Glama

Ground Truth - Fresh Evidence for AI Agents

by io.github.anish632

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.

Input Schema

TableJSON 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

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

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, but there are several lightly overlapping pairs (check_endpoint/preflight_endpoint, check_pricing/compare_pricing_pages, estimate_market/compare_competitors, test_hypothesis/verify_claim). The detailed descriptions and explicit 'do not use for' notes mitigate confusion, so misselection is unlikely.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case verb_noun pattern (e.g., check_endpoint, create_monitor, verify_claim). Even compound verbs like preflight_endpoint and run_monitor_now adhere to the same structure, making the naming fully predictable.

Tool Count4/5

19 tools is slightly heavy but reasonable for the broad scope covering endpoint checks, pricing, compliance, package research, claim verification, and monitor lifecycle. Each tool has a distinct role, though the count edges close to the 'heavy' range.

Completeness4/5

Core workflows are well-covered: create/list/delete/get/run/preview monitors, single and comparative pricing checks, endpoint and security verification, and claim testing. Minor gaps exist, such as no update_monitor tool or a way to explicitly verify a claim without pre-supplied evidence URLs, but these are workable.

Resources