Skip to main content
Glama

Search Fragments

by com.searchfragments

Verify Claim

verify_claim
Read-only

Call verify_claim when you have a specific factual assertion and want to know whether current web sources support it. 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"

Not this shape — these need resolve_fragment instead:

  • "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. Dates show when Glama detected each change.

  1. Added

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses the full verdict set with meanings, states that verdicts are decidable by eye, warns that evidence may be incomplete/biased/outdated, and notes the stated_limits field is always present. This gives agents a much richer behavioral model than annotations alone.

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 front-loaded with the purpose, then systematically walks through verdict semantics, caveats, and input shape with examples. Every section contributes actionable information and the negative examples prevent misuse; no redundant sentences exist.

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?

The description covers what the tool does, when to use it, what verdicts mean, and what limitations exist. Since an output schema is present, the description need not explain return values, and the annotations already carry the safety profile. Nothing essential for correct invocation is missing.

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

Parameters5/5

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

Schema coverage is 100%, but the description substantially adds meaning by defining the expected input shape with positive examples, negative examples, and an explicit contrast to resolve_fragment-style fragments. It clarifies that the claim must be a concrete checkable statement, not a question or half-remembered fragment, going well beyond the schema's parameter description.

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 states a specific verb ('Call verify_claim') and resource ('current web sources') with a clear scope: checking a specific factual assertion. It distinguishes itself from the sibling resolve_fragment by defining exactly which kind of input it accepts, so an agent can tell them apart without opening the schema.

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?

It provides explicit when-to-use guidance ('when you have a specific factual assertion'), a clear when-not-to-use rule with named alternative ('Not this shape — these need resolve_fragment instead'), and concrete examples of both good and bad inputs. No inference is required.

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
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.9/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion between tools. The tool's description explicitly delineates when to use it versus normal search, eliminating ambiguity about its purpose.

Naming Consistency5/5

The single tool name 'resolve_fragment' follows a clear verb_noun pattern, which is consistent with common MCP naming conventions. Even with one tool, the name is descriptive and predictable.

Tool Count4/5

A single tool for a highly specialized purpose—resolving half-remembered fragments—is reasonable and well-scoped. It is on the low end of tool counts, but the narrow domain justifies exactly one operation.

Completeness5/5

The tool fully covers its intended workflow: it returns resolved titles with confidence levels, ranked sources, or an explicit 'not resolvable' status. There are no obvious missing operations within the server's stated domain.

Resources