Skip to main content
Glama

graph_view

Render a scoped epistemic subgraph from a particle store to inspect subject neighborhoods, query hits, contradictions, or manifest sections with render-time confidence and provenance.

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 path resolves on the engine host.
    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.

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 provided, the description carries the full burden and does so well: it discloses that all epistemics are computed at render time and never stored, that hops/max_nodes are clamped by graph config with human-readable disclosures, that future as_of instants are rejected, that all_projects has no effect on an unbound server, and that the url field only appears when base_url is configured. This is exactly the behavioral context an agent needs for a tool with no annotation coverage.

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 mandatory-scope rule is front-loaded ahead of the argument list, and the Args/Returns structure is easy to scan. It is long and occasionally florid ('the anti-hairball invariant', 'the picture of the knowledge the agent consulted'), but those phrases are doing real disambiguation work rather than padding.

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 an 11-parameter tool with zero schema coverage, the description covers scope exclusivity, aliasing and clamping behavior, ordering/filter semantics, and the conditional url field. Output schema exists and is still summarized usefully (nodes, edges, particles, supersessions, census, disclosures), so an agent can call this correctly without opening any other resource.

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% across 11 parameters, so the description must compensate entirely and does: it documents accepted id forms (exact case-insensitive names/aliases for subject_id, unique prefixes for inconsistency_id, region id or title for section), defaults ('default' is the canonical store), and edge semantics (bare date = start of day UTC, future rejected, hops clamped). Nearly every parameter gains meaning beyond its bare title and type.

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 concrete verb ('Render') and a precise resource ('one scoped epistemic subgraph of the particle store'), and immediately constrains the scope modes. An agent can distinguish it from particles_list, query, or subjects_show because this returns a graph render rather than a flat listing or search result.

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?

Explicitly states the when-not ('a whole-store render does not exist; the anti-hairball invariant') and explains which scope argument selects which mode, effectively describing four alternative entry points. It does not, however, route the agent to sibling tools for simpler needs (e.g., particle_show for one particle), so it stops just short of full alternative guidance.

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