Skip to main content
Glama

Particle Catalog

particle_catalog
Read-only

Browse the full Particle tool catalog. Your tools/list shows only the default categories, but EVERY public Particle tool is callable by name regardless of what was advertised — call this tool to discover the rest.

Without arguments: the categorical menu (every category with tool names, one-line summaries, and an ↳ line listing each tool's expand options). With category: the full input schema for each of that category's tools, ready to call.

Two conventions the one-line summaries don't convey, so read tools through this lens:

  • Tools are lean by default and EXPAND. Most return a minimal payload and opt into richer sections via an include array (e.g. a company's people, products, and competitors; a person's roles and podcast appearances) or change behavior via a mode/format switch. The ↳ line names these — a tool does far more than its summary alone implies.

  • Responses are a graph; slugs are edges. A slug a tool returns (person, company, podcast, episode, publisher, guest) is a valid input to the other tools, so you resolve once and then traverse: company → its people → a person's podcast appearances → that episode's transcript and every entity in it.

Categories on offer:

  • system (always-on): Discovery meta-tools: browse the full tool catalog and call any tool by name.

  • podcasts (default): Resolve podcasts, list and fetch episodes, search transcripts, and find entity mentions.

  • people (default): Resolve people and entities to canonical handles and fetch person profiles.

  • companies (default): Resolve companies and fetch company profiles with people, products, and competitors.

  • topics (default): Browse the hierarchical topic taxonomy used to classify podcast episodes.

  • podcast_rankings (default): Podcast chart rankings: current charts, movers, and ranking history.

  • podcast_trends (default): Trending entities on podcasts: daily entity charts with movement and the quote behind it.

  • podcast_guests (default): Podcast guest directory, trending guests, and per-guest appearance profiles.

  • podcast_advertising (opt-in): Podcast advertising intelligence: sponsor rosters, ad presence, and sponsor leaderboards.

  • podcast_publishers (opt-in): Podcast publisher profiles with their shows, bias profile, and suitability profile.

  • podcast_ratings (opt-in): Listener review ratings for podcasts: summaries and recent rating lists.

  • podcast_bias (opt-in): Corpus-wide political-bias views: publisher leaderboards and publishers by bias result.

  • podcast_suitability (opt-in): Corpus-wide GARM brand-suitability views: publisher leaderboards and category exposure.

  • alerts (default): Create and manage alerts that watch entities for podcast mentions or speaker appearances, preview match frequency, and review the matches an alert has caught.

  • radar (opt-in): Display selected research results as embedded Radar cards, with a Markdown fallback. Rendering is free and does not fetch data.

Opt-in categories can also be advertised on tools/list by adding ?include=<category> (comma-separated, or all) to the connection URL, or the X-Particle-Include header. ?exclude= hides default categories; ?tools=<name,...> pins the advertised list to exact tools instead. Discovery is free; tool execution is metered and plan-gated as usual.

Input Schema

NameRequiredDescriptionDefault
categoryNoExposure category name (e.g. 'podcast_bias'). When set, the response includes the FULL input schema for every tool in that category — call this before invoking a tool you haven't seen advertised. When omitted, returns the categorical menu: every category with its tools and one-line summaries.
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. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/non-destructive/closed-world, yet the description still adds substantial behavior: discovery is free while execution is metered and plan-gated, and the catalog payload carries the `↳` expand-option line. It could go one step further on how large the no-argument menu response is, but the cost and response-shape context is well beyond what annotations provide.

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 leading paragraph front-loads the core insight (unadvertised tools are callable) before any detail, and the two convention bullets genuinely earn their space. The full category enumeration is somewhat redundant since the tool itself returns that menu, which costs it a point.

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 two-parameter, zero-required discovery tool with annotations covering the safety profile, the description covers what both modes return, the metering model, and the traversal model an agent needs to use the catalog effectively. Nothing about calling it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100% and both parameter descriptions already cover the category-vs-menu behavior and the markdown/json tradeoff, so the schema carries this dimension. The description's added detail is really cross-catalog convention (include arrays, mode/format switches) rather than meaning for these two parameters, which is helpful context but not parameter semantics.

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 ('Browse the full Particle tool catalog') and immediately explains the distinguishing premise: tools/list is incomplete, but every public tool is callable by name. It differentiates itself from the sibling meta-tool particle_call by being the discovery half of that pair.

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?

Explicit branching on when to call with no arguments (categorical menu) vs with `category` (full input schemas), plus the derived rule 'call this before invoking a tool you haven't seen advertised.' It also names the alternatives for getting the same information (?include=, ?exclude=, ?tools= URL params), so the agent can choose the right path.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources