particle-pro

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

Name	Required	Description	Default
`category`	No	Exposure 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_format`	No	Output 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.

First observedSep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: the no-args categorical menu vs. full-schema mode, the 'lean by default and EXPAND' convention, the graph/slugs-as-edges model, and the warning that JSON output is 'larger and noisier for an LLM to read.' These are non-obvious traits that materially affect how an agent uses the tool. No contradiction with annotations exists.

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 long but rigorously structured with bold headers, bullets, and a front-loaded purpose statement. Each section—categories, expansion conventions, graph traversal, opt-in configuration, and output format guidance—earns its place because this is a meta-tool that must explain the entire ecosystem to be useful. There is no filler or redundant restatement of the schema.

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 discovery tool with no output schema, the description is remarkably complete: it covers all categories, what each invocation mode returns, how to read the menu's '↳' expand lines, how slugs connect tool responses, and how to control advertised categories via URL query parameters or headers. An agent has everything needed to call it correctly and use the results to traverse the Particle ecosystem.

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, but the description adds operational meaning beyond the field descriptions: it explains that category triggers 'the FULL input schema for every tool in that category' and that markdown is the LLM-facing default while JSON is for programmatic exact extraction. It also enumerates the category options, effectively enriching the category parameter's possible values.

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?

The description opens with a specific verb and resource: 'Browse the full Particle tool catalog.' It also clearly distinguishes itself as a meta-tool compared to the functional sibling tools, explaining that tools/list only advertises default categories while this tool discovers every callable public tool. This is far more than a tautology or vague summary.

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?

The description explicitly says 'call this before invoking a tool you haven't seen advertised' and contrasts the advertised tools/list with the full catalog. It also explains when to use no arguments versus the category argument, and covers opt-in/exclusion mechanics via URL parameters or headers. This leaves no ambiguity about when to invoke it.

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

All particle-pro tools Inspect

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

Need Help?