Skip to main content
Glama
LinkedParticles

Particles

Official
by LinkedParticles
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

subjects_list

List subjects in a knowledge graph alphabetically or by connectivity to find hub topics and page through the full set. Use limit and offset to keep responses within token limits.

Instructions

List subjects in the knowledge graph (alphabetical by canonical_name).

Paginated to keep responses within an MCP-client-friendly size — the
full subject set can easily exceed per-tool-result token caps.

Args:
    limit: Maximum subjects to return (default 50).
    offset: Number of subjects to skip before returning results
        (default 0). Combine with ``limit`` to page through the
        full set.
    order: ``"name"`` (alphabetical, default) or ``"degree"`` —
        most-connected first, by descending count of ACTIVE
        particles linked to each subject (name tie-break). Use
        ``"degree"`` to find a store's hub subjects, e.g. as a
        ``graph_view`` starting scope.

Input Schema

NameRequiredDescriptionDefault
limitNo
orderNoname
offsetNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.210.2

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full load. It explains the pagination rationale (token caps) and clarifies that order='degree' uses active particle counts with a name tie-break. It does not state read/write intent, but 'List' implies read-only. The added behavioral context is solid, though not exhaustive.

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 well-structured: a front-loaded purpose sentence, a short paragraph on pagination rationale, and a clear Args section. Every sentence serves a purpose. It could be slightly tightened, but overall it is appropriately sized.

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 a simple list tool with three parameters, no annotations, and an output schema that handles return values, the description covers purpose, pagination, parameter semantics, and ordering. Nothing essential for correct invocation is missing.

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?

Although the input schema has 0% description coverage, the description includes a detailed Args section explaining limit, offset, and order, including defaults and the meaning of order values. This fully compensates for the schema gap and gives the agent everything needed to invoke the tool correctly.

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 description states a clear verb and resource: 'List subjects in the knowledge graph (alphabetical by canonical_name).' It distinguishes from a search by using 'List' and specifying the default ordering. However, it does not explicitly contrast with sibling tools like subjects_search or subjects_show, so it misses the top score.

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?

The description gives some usage context, e.g., using order='degree' to find hub subjects as a graph_view starting scope. But it offers no explicit when-to-use guidance relative to alternatives such as subjects_search or subjects_show, so the agent has to infer its place among siblings.

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