Skip to main content
Glama

Search Fragments

by com.searchfragments
OverviewDiscussionsAdmin

Verify Claim

verify_claim
Idempotent

Checks whether current web sources support a specific factual assertion. Takes a claim as a natural-language statement; returns a verdict with cited evidence and stated limits.

Verdict set:

  • "supported" — multiple independent sources directly confirm the specific claimed detail

  • "partially_supported" — sources confirm the entity and domain; specific detail is pointed to but not directly stated

  • "insufficient_evidence" — sources don't address the specific claim; fires freely, including when the entity is well-known but the specific detail is undocumented

  • "unsupported" — a credible source explicitly contradicts the claim

All verdicts are DECIDE-BY-EYE. A "supported" verdict means current web sources confirm it — not that it is true. Evidence may be incomplete, biased, or outdated. The stated_limits field is always present and identifies what the evidence cannot confirm.

Good input shape (specific, checkable assertions):

  • "Werner Herzog dragged a full-size steamship over a hill during the filming of Fitzcarraldo"

  • "Glenn Gould stopped giving live concerts in 1964"

  • "The Backrooms photograph originated on 4chan"

Checks one specific factual statement. Not for identifying half-remembered works.

Not this shape:

  • "there's a documentary about a filmmaker dragging a boat over a mountain"

  • "a musician famous for stopping performing"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
claimYesA specific factual assertion to check against current web sources. Should be a concrete, checkable statement — not a question or a half-remembered fragment.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
verdictYes'supported' = multiple independent sources directly confirm the specific claimed detail. 'partially_supported' = sources confirm entity + domain; detail pointed to but not directly stated. 'unsupported' = a credible source explicitly contradicts the claim. 'insufficient_evidence' = pool doesn't address the specific claim; fires freely.
evidenceYesWeb sources retrieved. Always DECIDE-BY-EYE — human must verify before acting.
stated_limitsYesWhat the evidence cannot confirm, even when verdict is supported. Always present.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover safety flags, but the description adds the whole verdict taxonomy (supported/partially_supported/insufficient_evidence/unsupported) with firing conditions, the critical 'DECIDE-BY-EYE' framing that 'supported' means sources confirm rather than truth, and the guarantee that stated_limits is always present. That is rich behavioral context unavailable in the structured fields.

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?

Front-loaded with purpose, then a clearly labeled verdict set, then input-shape guidance. Slightly long, but each block (verdict definitions, decide-by-eye caveat) carries decision-relevant information rather than padding.

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?

For a single-param tool with an output schema, the description covers everything an agent needs: invocation criteria, verdict interpretation, and the reliability caveat. Return-value details are deferred to the output schema, which exists.

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?

Schema coverage is 100% with a single, fully documented parameter, so baseline is 3. The description adds genuine meaning beyond the schema by showing the required input shape (specific, checkable assertions vs. half-remembered fragments) and the 500-char-scale intent.

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+resource ('checks whether current web sources support a specific factual assertion') and defines the output shape (verdict + cited evidence). It also explicitly carves out what it is NOT ('Not for identifying half-remembered works'), which separates it cleanly from the resolve_fragment sibling.

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?

Gives explicit when-to-use examples ('Werner Herzog dragged a full-size steamship...') and explicit non-examples ('a musician famous for stopping performing'), plus the rule that it checks one specific factual statement. An agent can decide between this and resolve_fragment without inference.

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

All Search Fragments 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