Skip to main content
Glama

particle_show

Retrieve one particle by UUID or 8+ character prefix to inspect its provenance, subjects, tags, and any restated wording, so you can trace every claim back to its source.

Instructions

Show one particle with its provenance, subjects, and tags.

Args:
    particle_id: Full UUID or unambiguous prefix (≥ 8 chars).

Returns:
    Dict with ``particle`` (Pydantic JSON), ``subjects`` (list of
    ``{id, canonical_name}``), and ``provenance`` (list of
    ``{type, corpus_entry_id, uri_r, source_type, snapshot_id}``).
    When the source now states the claim in other words, ``restated_as``
    holds that wording and its snapshot; the claim's
    ``content`` keeps its first wording. Raises if the prefix matches zero
    or multiple particles.

Input Schema

NameRequiredDescriptionDefault
particle_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.210.2

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden well: it describes the returned structure, explains restated_as and that content keeps its first wording, and states that zero or multiple prefix matches raise. It does not explicitly restate read-only/safety properties, but 'show' clearly implies a non-mutating retrieval.

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?

The description is front-loaded with the tool's purpose, then cleanly structured into Args and Returns sections. The return-value detail is dense but each element adds useful semantics, especially around restated_as and content wording.

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?

Although an output schema exists, the description adds needed semantic context about provenance and restated_as, and it fully explains the single argument and error behavior. An agent has enough information to invoke this correctly and interpret key return fields.

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 explain the only parameter. It does so fully: particle_id accepts a full UUID or an unambiguous prefix of at least 8 characters, and ambiguous prefixes raise.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: 'Show one particle with its provenance, subjects, and tags.' This clearly distinguishes a single-entity retrieval from list/search siblings such as particles_list and particle_search, though it does not explicitly name those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied by the single-particle scope, and the description helpfully notes that ambiguous prefixes raise an error. However, it does not explicitly say when to use this tool versus particle_search, particles_list, or other retrieval siblings, leaving selection mostly to inference.

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