Skip to main content
Glama

graph_view

Render a scoped epistemic subgraph from the particle store by subject, query, inconsistency, or manifest section, with confidence, contested badges, and as-of visibility computed at render time.

Instructions

Render one scoped epistemic subgraph of the particle store.

Scope is mandatory — pass exactly one of ``subject_id`` / ``query`` /
``inconsistency_id`` / ``manifest``+``section`` (a whole-store render
does not exist; the anti-hairball invariant). Every
epistemic quantity in the result (effective confidence, contested
badges, as-of visibility, utility evidence) is computed at render time
by the engine and never stored.

Args:
    subject_id: Neighbourhood scope — this Subject, its particles, and
        subjects reachable within ``hops`` via multi-subject particles.
        Accepts a subject id or an exact (case-insensitive) canonical
        name / alias; the render's ``scope_ref`` is the resolved id.
    query: Retrieval-set scope — the top-K hits of the existing query
        ranking rendered as their subjects plus the hit particles
        ("the picture of the knowledge the agent consulted").
    inconsistency_id: Evidence scope — a contradiction's
        picture: the INCONSISTENCY particle as the anchor, its two
        disputant beliefs shown with their true statuses (the
        quarantined side included), their subjects and sources. Accepts
        a full particle id or a unique prefix (a contested badge's
        ``inconsistency_id`` is the usual source).
    manifest: With ``section``, projection scope — an
        manifest section's deterministic selection rendered as
        a graph. The manifest is a relative name under the engine's
        ``graph.manifest_root``; with that unset the scope is refused.
    section: The manifest section's ``region`` id, or its exact
        (case-insensitive) title.
    hops: Neighbourhood radius for subject scope (clamped to
        ``graph.max_hops``).
    history: Also include retired supersession-chain ancestors, rendered
        as ghosts.
    as_of: ISO-8601 past instant (a bare date means start of that day,
        UTC): render the graph as believed at T. A future
        instant is rejected.
    max_nodes: Per-call node cap (clamped to ``graph.max_nodes``).
    store: Store handle to render from; ``"default"`` is the
        canonical store.
    all_projects: On a server bound to one project, render from
        the whole store instead of that project's view. The result says so.
        No effect on an unbound server.

Returns:
    The ``GraphData`` render as JSON — ``nodes`` (subjects with display
    aggregates), ``edges`` (multi-subject particles), ``particles``
    (per-particle epistemics payloads keyed by id), ``supersessions``,
    the ``census``, and human-readable ``disclosures`` for any cap that
    bound. When ``engine.base_url`` is configured, a ``url`` field
    additionally deep-links the same scope on the unified web UI
    (``/app#/browse?…``) so the operator can open the
    interactive picture — the default stdio install has no HTTP server,
    so the field is additive, never assumed.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "graph_view"
  }
}

Input Schema

NameRequiredDescriptionDefault
hopsNo
as_ofNo
queryNo
storeNodefault
historyNo
sectionNo
manifestNo
max_nodesNo
subject_idNo
all_projectsNo
inconsistency_idNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.210.2

TDQS

A4.7/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 behavioral burden and does so thoroughly: epistemic values are computed at render time and never stored, caps are clamped and disclosed, history ghosts are opt-in, as_of rejects the future, manifest scope depends on graph.manifest_root, and all_projects only affects project-bound servers.

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 text is front-loaded and well structured around purpose, mandatory scope, Args, and Returns. It is long, but the length is mostly justified by 11 undocumented parameters; the Returns section is somewhat redundant given the output schema and includes some ornate phrasing.

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?

For a complex 11-parameter rendering tool with no annotations, the description is complete: it explains scope selection, parameter behavior, runtime computation, caps, configuration dependencies, and return shape. An agent has enough information to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it documents all 11 parameters. It adds acceptance rules (id, exact case-insensitive name/alias, unique prefix), resolution behavior (scope_ref), config dependencies, clamping behavior, UTC date handling, and the canonical default store.

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 description opens with a specific verb and resource: 'Render one scoped epistemic subgraph of the particle store.' It clearly distinguishes the tool from list/search/show siblings by tying it to graph rendering with mandatory scope, and the scope enumeration reinforces exactly what kind of subgraph is produced.

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?

It gives strong selection rules: scope is mandatory, exactly one of subject_id/query/inconsistency_id/manifest+section is required, and whole-store renders do not exist. Each scope mode is explained with its intended semantics, though it does not explicitly compare against sibling tools such as particle_show or query.

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