Skip to main content
Glama

particle-pro

by pro.particle
OverviewDiscussionsAdmin

Particle Topic Browse

particle_topic_browse
Read-only

Navigate the topic taxonomy. Without parent_slug, returns the top-level roots (Politics, Business, Technology, etc.). With parent_slug set, returns the direct children of that topic. Topic slugs use a parent/child convention (e.g. politics/elections) and let agents browse the hierarchy to find well-named categories.

To find a topic by name instead of walking the tree, pass query (e.g. artificial intelligence): exact names rank first, then prefixes, then substrings (for a word of 3+ characters), each by story coverage, and parent_slug narrows the search to that subtree. The same name often sits under several parents, so read the ancestry before picking a slug. Topic slugs feed the topic_slug filters on particle_podcast_resolve and particle_podcast_list_guests.

Input Schema

NameRequiredDescriptionDefault
limitNoTopics per page (1-100, default 50).
queryNoFind topics by name: exact names first, then names starting with it, then (when it has a word of 3 or more characters) names containing it, each ranked by story coverage. Covers topics with at least 5 story clusters; browse with parent_slug for the long tail. Pages reach the top 200 matches.
cursorNoOpaque pagination cursor from a previous response.
parent_slugNoTopic slug or ID. Returns the direct children of this topic. Omit for top-level roots (Politics, Business, Technology, etc.). With query, limits the search to this topic's descendants.
output_formatNoOutput serialization. 'markdown' (default) returns the LLM-facing rendering. 'json' returns the structured payload as JSON text — use only for programmatic chaining where exact field extraction matters; the JSON shape is larger and noisier for an LLM to read.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / parent_slug / description
      Previous value: -"Topic slug or ID. Returns the direct children of this topic. Omit for top-level roots (Politics, Business, Technology, etc.)."New value: +"Topic slug or ID. Returns the direct children of this topic. Omit for top-level roots (Politics, Business, Technology, etc.). With query, limits the search to this topic's descendants."
    • addedInput schema / properties / query
      Added value: +{
+  "description": "Find topics by name: exact names first, then names starting with it, then (when it has a word of 3 or more characters) names containing it, each ranked by story coverage. Covers topics with at least 5 story clusters; browse with parent_slug for the long tail. Pages reach the top 200 matches.",
+  "maxLength": 100,
+  "minLength": 2,
+  "type": "string"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only establish the read-only, non-destructive, closed-world profile. The description goes well beyond: it discloses the ranking order (exact, prefix, substring by story coverage), the query mode's coverage floor ('at least 5 story clusters'), a 200-match page ceiling, and a real caution that the same name sits under several parents so ancestry must be read first.

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?

Two tight paragraphs, front-loaded with the primary browse behavior before the query alternative. It is slightly repetitive with the schema's query-ranking wording, and the downstream-tool sentence could be trimmed, but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-param, no-required, read-only browse tool with no output schema, the description covers both modes, ranking, coverage limits, pagination ceiling, and downstream slug usage. It does not describe the shape of an individual returned topic, which is a minor gap given no output schema exists.

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 adds genuinely non-schema meaning: the parent/child slug convention with an example ('politics/elections') and the fact that parent_slug narrows query to that subtree. Minor redundancy with the schema's own query ranking text keeps it from a 5.

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 specific verb and resource ('Navigate the topic taxonomy') and precisely defines both operating modes: no parent_slug returns top-level roots, with parent_slug returns direct children. No sibling tool in this server does taxonomy browsing, so the agent can identify it immediately.

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?

Explicitly contrasts the two paths: walk the tree via parent_slug, or 'to find a topic by name instead of walking the tree, pass query.' It also names the downstream consumers ('topic_slug' filters on particle_podcast_resolve and particle_podcast_list_guests), telling the agent why it would call this before those.

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

All particle-pro toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources