Skip to main content
Glama

Phone

by io.github.pipeworx-io

Validate Claim

validate_claim
Read-onlyIdempotent

"Is it true that…" / "fact check" / "verify the claim that…" / "did X really…" / "was Y actually…" / "confirm or refute" / "true or false" — natural-language claim verification against authoritative sources. Use whenever the agent needs to check whether something a user said is factually correct. Company-financial claims (revenue, net income, cash for public US companies) verify via the structured SEC EDGAR + XBRL fast path with exact percent-delta math; ANY OTHER factual claim (macro statistics, rates, prices, drug data, records) automatically falls through to the grounded pipeline — routed to the right live source, answered with verbatim evidence, then judged. Returns a verdict (confirmed / approximately_correct / refuted / inconclusive / unsupported / could_not_verify), the grounded or structured actual value with pipeworx:// citation, and reasoning. IMPORTANT for callers: could_not_verify means the check did not happen (our LLM or source failed) and carries verification_error{stage,detail} — it is NOT evidence for or against the claim, and must not be shown as one. unsupported means we looked and cover no source for it. Replaces 4–6 sequential calls (NL parsing → entity resolution → data lookup → comparison).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
claimYesNatural-language factual claim, e.g., "Apple's FY2024 revenue was $400 billion" or "Microsoft made about $100B in profit last year".
tolerance_pctNoMax percent deviation still graded approximately_correct (0.5–50). Overrides the tolerance implied by the claim wording — set 1–2 for hallucination detection where any material error must be refuted. Default: implied by wording, capped at 5.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / tolerance_pct
      Added value: +{
+  "description": "Max percent deviation still graded approximately_correct (0.5–50). Overrides the tolerance implied by the claim wording — set 1–2 for hallucination detection where any material error must be refuted. Default: implied by wording, capped at 5.",
+  "type": "number"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, openWorld, non-destructive). The description adds valuable behavioral nuance beyond annotations: the meaning of could_not_verify vs. unsupported, the routing paths, and the return structure. This is exactly the kind of context that helps an agent interpret results correctly, especially the warning that could_not_verify is not evidence.

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 somewhat long but every sentence earns its place: user intents, use case, routing, return values, verdict semantics, and efficiency justification. It is front-loaded with examples and structured logically, with the important caller warning called out explicitly. No wasted words.

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?

Despite no output schema, the description fully explains the return value shape (verdict, value, citation, reasoning) and the two key failure modes. It covers routing for different claim types, parameter overrides, and the protocol around could_not_verify. For a tool of this complexity, this description is highly complete.

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 descriptions cover 100% of parameters, but the description enriches the semantics significantly. It explains tolerance_pct as overriding the wording-implied tolerance, gives a concrete use case (hallucination detection with 1-2), and clarifies the default cap. Claim examples in the schema are reinforced. This adds real value beyond the structured schema.

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 clearly states the tool's purpose: natural-language claim verification against authoritative sources, with a verdict and evidence. It provides specific user phrasings ("Is it true that…") and distinguishes itself from sibling research tools by focusing on fact-checking with defined judgment categories. This is a specific verb+resource description with strong differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct' and provides routing rules for company-financial vs. other claims. It does not name specific alternative tools like ask_pipeworx_grounded or deep_research, but the context is clear enough to guide tool selection. A slightly more explicit exclusion or mention of alternatives would push to 5.

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

All Phone 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/5.0
Disambiguation4/5

Tool purposes are mostly distinct, with detailed descriptions differentiating similar-sounding tools like ask_pipeworx, ask_pipeworx_grounded, and deep_research. However, some overlap exists between bet_research and polymarket_* tools, requiring careful reading of descriptions to select the correct one.

Naming Consistency3/5

Tool names mix verb_noun patterns (e.g., resolve_entity, validate_claim) with noun_phrases (e.g., entity_profile, recent_alerts) and occasional inconsistencies like pipeworx_trending or search_within. While most names are readable, the lack of a uniform convention makes it harder to predict tool names.

Tool Count4/5

32 tools cover a broad domain of data retrieval, analysis, prediction markets, and system management. The count is high but reasonable given the extensive feature set, though a more focused set could improve coherence.

Completeness4/5

The tool set covers major needs: data lookup, comparison, validation, monitoring, and memory. Missing CRUD operations for external data are expected as this is a read-centric API, so gaps are minor and don't hinder common tasks.

Resources