Skip to main content
Glama

Verify Quote

verify_quote
Read-onlyIdempotent

Verify, check, or confirm a Buddha quote — does the canon really say it?

Fact-check a quotation attributed to the Buddha. Catches fake, misquoted, misattributed and misremembered passages, and finds the true reading.

Paste a line that has been quoted or half-remembered — Pāli or English — and this says whether the canon really contains it, cites where, and if not, shows the closest thing that is actually there.

🧭 When to use this:

  • A quote is attributed to the Buddha and you are not certain it is real. A fabricated line that sounds canonical is the hardest error to catch by reading, because it reads correctly. Check it instead of trusting it.

  • Someone recalls a passage imperfectly, or a chanted form has drifted from the written one. The tool shows the received text beside theirs.

  • Before repeating any Pāli you did not get from these tools, verify it. This is cheap and it is the difference between citing and guessing.

⚠️ Do not present an unverified passage as canonical. If the verdict is not_found, say plainly that the line is not in the canon rather than quoting it with a hedge — a hedged fabrication still spreads.

⚖️ Verdict thresholds. exact = contained or similarity ≥ 0.995; close = coverage ≥ 0.85 and similarity ≥ 0.55; else not_found. exact means letters matched once folded, not that a human confirmed the reading. Matches also carry coverage (your letters present, in order), contained (present whole) and spans (segments joined; >1 → segment_id is the first only).

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": {
      "text": "<text>"
    },
    "name": "verify_quote"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesThe passage as quoted. Diacritics optional, folded internally. One line works best; the canon is segmented line by line, so a quote spanning several segments may only match in part.
limitNoHow many near matches to return when it is not exact (1–10).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuine behavioral context — verdict thresholds and match fields (coverage/contained/spans, segment_id) — but much of this overlaps with the output schema, which already documents return structure. Useful but partially redundant with 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 the core purpose, then cleanly sectioned into usage and thresholds. It is long, but the sections are scannable and each earns its place; slight verbosity in the warnings keeps it from a 5.

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 an output schema exists, the description needn't restate returns, yet it still surfaces the verdict semantics an agent needs to act correctly. Nothing required to invoke or interpret the tool is missing.

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%, so the schema already documents both parameters. The description adds real meaning beyond it: input may be Pāli or English, and the line-segmentation caveat explains why a multi-segment quote may only partially match. This exceeds the baseline-3 expectation.

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 — fact-check a quotation attributed to the Buddha — and clarifies scope (Pāli or English, cites where, shows the closest real passage if absent). It is clearly distinguishable from the search/get siblings, which retrieve rather than verify.

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?

Contains an explicit 'When to use this' section with concrete triggers (uncertain quote, imperfect recall, drifted chanted form) plus an explicit when-not with a directive on how to report a not_found verdict. Conditions for use are spelled out rather than inferred.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources