Skip to main content
Glama
Sign In
PROVE IT

PROVE IT

Official
by ark-forge
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

proveit_read

Reads one compliance corpus resource through a Trust Layer proxy to produce a fresh proof receipt and return the exact body served; each call creates a new proof.

Instructions

Read one resource of the corpus through the Trust Layer proxy. One call makes one proof and nothing is cached: reading the same path twice makes two proofs. Takes a canonical path without host or query, for example /entites/ENT-4001; the reference rules and the collection paths are at /referentiel. Returns the proof_id and the body exactly as served. Refused when the season is closed.

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": {
      "path": "<path>"
    },
    "name": "proveit_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and delivers real behavioral detail: one call produces exactly one proof, nothing is cached, returns proof_id plus the body as served, and the call is refused when the season is closed. Gaps remain around auth/identity handshake via the Trust Layer and the shape of a refusal, which keeps it below a 5.

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?

Four compact sentences, front-loaded with the core purpose, then the proof/no-cache semantics, then path guidance, then the refusal condition; nothing is filler. Only the phrase "the reference rules and the collection paths are at /referentiel" is slightly compressed to the point of ambiguity.

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?

For a one-parameter read tool with no annotations and no output schema, the description covers purpose, path format, proof semantics, and return payload, which is nearly everything an agent needs. Missing only the mechanics of the Trust Layer identity and what a refusal looks like at the call site.

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?

The schema documents nothing (0% coverage), so the description must compensate, and it does: the single path parameter is a canonical path, must exclude host and query, comes with a concrete example (/entites/ENT-4001), and points to /referentiel for the reference rules and collection paths. It does not specify encoding or behavior for a non-canonical path, so a 4 rather than 5.

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 one resource of the corpus through the Trust Layer proxy") with a clearly bounded scope, and it is trivially separable from siblings like proveit_enroll, proveit_submit, and proveit_status, which are all non-read operations. An agent can tell what this does 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 concrete usage context: the read must target a canonical path without host or query, and calls are not cached so repeated reads intentionally yield multiple proofs. It also states the refusal condition ("Refused when the season is closed"). It stops short of pointing to an alternative retrieval tool, but the guidance is clear enough to select and invoke correctly.

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

Deploy Server

Other Tools