NEUS MCP

Read proofs

proofable_proofs_get

Read-onlyIdempotent

Read a proof by qHash or search proofs by scope, tags, verifier, or text. With no filter, returns an index hint; scope=all pages metadata. Use include=content for proof bodies and includeComments with qHash for discussion. Omit identifier when signed in.

Input Schema

Name	Required	Description
`q`	No	Full-text search (by-wallet ?q= when supported).
`tags`	No	Exact tag values: an array, or one comma-separated string. A proof matches when it carries any one of them; use tagPrefixesAll to require every one. Takes precedence over scope; use values from the proof index.
`depth`	No	With traverse: how many edges to follow from the proof. Default 1.
`limit`	No	Records per page. Default 15, max 25.
`qHash`	No	Optional proof id. When set, returns that one record instead of a vault page.
`scope`	No	Optional preset when tags omitted: memory \| research \| rules \| instruction \| tools \| jobs \| receipts. Use scope=all to list every proof newest first, and tags for arbitrary tags. Pair a scope with include=content to read a whole page of bodies in one call.
`offset`	No	Pagination offset (default: 0)
`include`	No	Default metadata. content requires a known qHash or narrowing filter; scope=all does not unlock bodies. Filtered content pages are capped at source.
`traverse`	No	With qHash: follow this proof's edges of one kind and return the connected records.
`tagPrefix`	No	Return proofs with a tag that starts with this prefix.
`identifier`	No	Wallet address (EVM 0x... or Solana base58) or DID (did:pkh:...)
`verifierId`	No	Optional check ID filter. Use it to request only proofs from one check.
`agentWallet`	No	Optional agent wallet for reading proofs under granted permissions.
`tagContains`	No	Return proofs with a tag containing this text.
`tagPrefixesAll`	No	Prefixes that must each match the start of some tag: an array, or one comma-separated string.
`includeComments`	No	Include comments for one known proof. Requires qHash; comment visibility follows proof access.

Output Schema

Name	Required	Description	Default
`data`	No
`error`	No
`status`	No
`message`	No
`success`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026
RemovedSep 30, 2026
AddedSep 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower, yet the description adds real context: the index-hint fallback with no filter, the metadata paging behavior of scope=all, the content-access constraint, and the auth shortcut of omitting identifier when signed in.

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?

Four dense sentences, front-loaded with the primary read/search modes and followed by the parameter pairings that matter. No padding or restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the main retrieval paths, defaults, and auth behavior for a 16-parameter tool, and the output schema handles return values. However, graph traversal (traverse/depth) is a distinct capability completely absent from the description, leaving an agent dependent on the schema to discover it.

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 baseline is 3; the description adds value by explaining parameter interlock rather than definitions — includeComments requires qHash, include=content needs a known qHash or narrowing filter, and identifier may be omitted when signed in.

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 and resource ('Read a proof by qHash or search proofs') and enumerates the alternative access modes (by scope, tags, verifier, text). An agent can distinguish this read/index tool from the mutating siblings (proofs_update, proof_revoke) 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 Guidelines4/5

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

Gives clear mode-selection guidance: no filter returns an index hint, scope=all pages metadata, include=content unlocks bodies, includeComments requires qHash, and identifier can be omitted when signed in. Strong internal routing, though it never explicitly contrasts with sibling tools like proofs_check or context.

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

All NEUS MCP tools Inspect

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.