Reality Graph Verification Tools

Fetch a knowledge base document

fetch

Read-only

Fetch a document from the Reality Graph knowledge base by id (as returned by search, e.g. '/verification-debt') or by full realitygraph.dev URL. Returns the document's summary, definitions, key facts, FAQ, and sources as text, plus the canonical URL.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	Document id from search results, or a realitygraph.dev URL

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`url`	Yes
`text`	Yes
`title`	Yes
`metadata`	No

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds what the tool returns (summary, definitions, key facts, FAQ, sources, canonical URL), providing context beyond the safety profile.

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?

Two sentences, no fluff. Front-loaded with purpose and key details. Every sentence adds value.

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?

With output schema present, description doesn't need to detail return structure, but it still lists key fields returned. Input is fully described. Complete for a simple fetch tool.

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 coverage is 100% and the description's parameter explanation mirrors the schema's description exactly. No additional meaning beyond what the schema already provides.

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?

Clearly states the verb 'Fetch', the resource 'document from the Reality Graph knowledge base', and the input methods (by id or URL). Distinguishes from sibling 'search' which returns search results, not a single document.

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?

Specifies two valid input formats (id or URL). Does not explicitly mention when not to use or alternatives, but the sibling list provides context. Clear enough for basic usage.

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

All Reality Graph Verification Tools tools Inspect

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.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose, ranging from capacity planning to template generation and validation. There is no functional overlap; even the two template tools (get_task_contract_template and get_verification_report_template) serve different artifacts.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using lowercase with underscores. Verbs like calculate, check, fetch, get, lint, plan, search, and validate clearly indicate actions, and the nouns are specific and singular.

Tool Count5/5

With 10 tools, the surface is well-scoped for the domain of AI coding verification. Each tool addresses a specific task without redundancy, and the count feels appropriate for a focused but complete tool suite.

Completeness5/5

The tool set covers the full lifecycle of verification: planning (plan_change_verification), specification (get_task_contract_template, lint_task_spec, validate_task_contract), execution (check_release_readiness, check_verification_debt, calculate_verification_capacity), and reporting (get_verification_report_template, fetch, search). No obvious gaps are evident.

Resources

Need Help?