Skip to main content
Glama

methodist_document_profile

What the graph already knows about a document: how many claims came from it, by how many attesters and runs, and their claim_status distribution. ★ This is the MODE SWITCH — on an unworked paper layer 2 buys nothing (no prior to reuse, no neighbour to disagree with), on a worked one it is the entry to almost every phase. ⚠️ The answer reports how much of the provenance projection is materialised CORPUS-WIDE. Below 1.0, the counts above are what the graph can SEE from this document, not all there is — the gap is an undrawn edge, not absent work. Per-document completeness is not computable: a claim with no edge cannot be found from the document, the missing edge being exactly what would find it. Accepts our document id or an arXiv id. Deterministic, no model call. ★ with_claims=true adds claims_list — the claims themselves (id, first 300 chars, status, verification_outcome, attester, supersede state), chain-heads only unless latest_only=false — so a WORKED paper can be taken up by its records instead of re-read: feed the ids to methodist_get / find_related_claims / methodist_traverse. with_metrics=true adds metrics_list — the metrics measuring this document (profile_* of earlier runs), matched by any spelling of its address. Addresses: document_id is the corpus uuid, node_id the graph node (document:arxiv:) — the same two names every document door carries; graph_node_id is the older spelling of node_id, kept.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNowindow over claims_list, default 200 (the whole list up to 200; claims_truncated only beyond)
offsetNostart of the claims_list window (0-based) for lists longer than limit; claims_total says how many there are
run_idNoOptional. The active methodist run_id (as returned by the methodist diagnose / get_current_dose door). Pass it whenever you call this tool while working inside a run, so the call is attributed to that run for the §8 usage crosscheck — attribution is run-anchored, so it stays correct even if your access token refreshes mid-run. Must be YOUR run: a run_id owned by a different principal, or a non-existent run_id, is rejected.
documentYesdocument id (uuid) or arXiv id, e.g. 2508.11122
latest_onlyNoclaims_list: chain-heads only (default TRUE); false lists superseded claims too, stamped
with_claimsNoalso list the claims derived from this document (default off)
with_metricsNoalso list the metrics that MEASURE this document (metric.measures_entity names it, in any spelling) — the profile a repeat review starts from (default off)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"window over claims_list, default 20"New value: +"window over claims_list, default 200 (the whole list up to 200; claims_truncated only beyond)"
    • changedInput schema / properties / limit / maximum
      Previous value: -100New value: +200
    • addedInput schema / properties / offset
      Added value: +{
      +  "description": "start of the claims_list window (0-based) for lists longer than limit; claims_total says how many there are",
      +  "minimum": 0,
      +  "type": "integer"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / with_metrics
      Added value: +{
      +  "description": "also list the metrics that MEASURE this document (metric.measures_entity names it, in any spelling) — the profile a repeat review starts from (default off)",
      +  "type": "boolean"
      +}
  3. Changed3 schema fields changed
    • addedInput schema / properties / latest_only
      Added value: +{
      +  "description": "claims_list: chain-heads only (default TRUE); false lists superseded claims too, stamped",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "window over claims_list, default 20",
      +  "exclusiveMinimum": 0,
      +  "maximum": 100,
      +  "type": "integer"
      +}
    • addedInput schema / properties / with_claims
      Added value: +{
      +  "description": "also list the claims derived from this document (default off)",
      +  "type": "boolean"
      +}
  4. Added

TDQS

A4.8/5.0
Behavior5/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: it discloses determinism ('Deterministic, no model call'), the corpus-wide materialization caveat ('Below 1.0... the gap is an undrawn edge, not absent work'), and the non-computability of per-document completeness. It also discloses run_id attribution behavior, including rejection of run_ids owned by another principal — all traits no structured field could convey.

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?

The description is long but organized with visible markers (★, ⚠️) and front-loads the core purpose in the first sentence. Most paragraphs earn their length — the caveat and workflow routing are load-bearing — though phrasing like 'the same two names every document door carries' adds color rather than information.

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 zero annotations and no output schema, the description compensates exceptionally: it describes the base answer (counts, attesters, runs, claim_status distribution), the two optional expansions, the data-materialization caveat, and the address spellings. Nothing an agent needs to call this 7-parameter tool correctly is left unexplained.

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 baseline is 3; the description earns more by adding workflow meaning: with_claims 'chain-heads only' deploys the results ('feed the ids to methodist_get / find_related_claims / methodist_traverse'), and with_metrics is 'matched by any spelling of its address' — a detail absent from the schema. The addresses paragraph clarifies the document-id / node-id / graph_node-id naming convention that the schema does not cover.

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 opening sentence states a specific verb-resource pair: 'what the graph already knows about a document' — an aggregate profile of claims, attesters, runs, and claim_status distribution. It positions itself as the 'MODE SWITCH' and entry point to 'almost every phase' on worked papers, separating it from fact-fetch tools (methodist_get) and traversal tools among its siblings. Accepting both uuid and arXiv ids and being deterministic ('no model call') further pins down its contract.

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?

The description is explicit about when it pays off: on a worked paper it is 'the entry to almost every phase,' while on an unworked paper 'layer 2 buys nothing (no prior to reuse, no neighbour to disagree with)'. It names concrete alternatives for taking up a worked paper — 'feed the ids to methodist_get / find_related_claims / methodist_traverse' — so an agent can route correctly without opening any sibling schema.

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.