Skip to main content
Glama

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_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

TableJSON 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.8/5.0
Behavior5/5

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

Annotations provide readOnlyHint=true, and the description adds rich context beyond it: discovery is free while tool execution is metered and plan-gated, responses are graphs where slugs are edges, and tools are lean by default with expand/mode conventions. This materially changes how an agent would call the tool.

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?

Long, but justified for a catalog tool whose job is to describe the whole API surface. It is front-loaded with the core purpose and the two conventions before the category list, and each section earns its place. A tighter category list would be possible, hence not a 5.

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?

Complete for a discovery tool: both modes, the expand convention, the graph/slug traversal model, all categories with default/opt-in status, and the mechanism to advertise opt-in categories are covered. No output schema exists, so the description's explanation of the markdown vs json return shapes fills that gap.

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 schema documents both parameters well. The description adds value beyond the schema by explaining the behavioral difference of each mode (menu vs full schemas) and by advising json format only for programmatic chaining. Slight deduction for not detailing the exact categorical menu structure.

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+resource ('Browse the full Particle tool catalog') and clearly distinguishes itself from the sibling tool surface by explaining that tools/list only advertises default categories while this tool discovers the rest. The two operating modes (menu without args, schemas with category) are explicit.

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 tells the agent when to call this tool ('call this before invoking a tool you haven't seen advertised') and names the alternatives — advertising opt-in categories via ?include=, ?exclude=, and ?tools= on the connection URL or X-Particle-Include header. Nothing is left to inference.

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