particle-pro

Particle Podcast Get Guest

particle_podcast_get_guest

Read-only

A guest's podcast-appearance profile: lifetime stats (appearances, distinct podcasts, first/last appearance) plus their most frequent podcasts. Guests are people — the same slug works with particle_person_get for the biographical profile.

Request optional sections via include: 'appearances' for the most recent episode appearances (episode and podcast slugs included for follow-up calls), 'podcasts' for the per-podcast rollup, 'suitability' for brand-suitability exposure across the podcasts they appear on, 'recommended_podcasts' for the five shows they could plausibly appear on next — shows related to the ones they have guested on, with the venues behind each pick and each show's suitability tier, latest episode and chart breadth (the pitch list; branch on each row's band). It already leaves out every show they have appeared on, other feeds of those shows with the same host, shows that stopped publishing and UNSAFE shows, and ranks shows far smaller than their usual venues lower, so there is no need to check each pick's episodes, 'in_field_appearances' for the most recent appearances where they spoke within their own field of expertise (what they know is what the episode drew on; particle_person_get with include: ["expertise"] says what that field is).

Returns not_found for people who exist but have never appeared on a podcast — use particle_person_get for those.

Input Schema

Name	Required	Description
`include`	No	Optional response sections: 'appearances' (most recent episode appearances with episode/podcast slugs), 'podcasts' (per-podcast rollup of where they appear), 'suitability' (brand-suitability exposure across the podcasts they appear on), 'recommended_podcasts' (the five shows they could plausibly appear on next — shows related to the ones they have guested on, each with the venues that led there, its suitability tier, latest episode and chart breadth; shows they appeared on, same-host sibling feeds, dormant and UNSAFE shows are already left out; the pitch list), 'in_field_appearances' (most recent appearances where they spoke within their own field of expertise). Default response is the profile + lifetime stats.
`guest_slug`	Yes	Person slug (e.g. 'sam-altman') from particle_podcast_list_guests, particle_person_resolve, or particle_entity_resolve.
`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.

Changed1 schema field changedOct 25, 2026

changedInput schema / properties / include / description

Previous value: -"Optional response sections: 'appearances' (most recent episode appearances with episode/podcast slugs), 'podcasts' (per-podcast rollup of where they appear), 'suitability' (brand-suitability exposure across the podcasts they appear on), 'recommended_podcasts' (the five shows they could plausibly appear on next — shows related to the ones they have guested on, minus those, each with the venues that led there; the pitch list), 'in_field_appearances' (most recent appearances where they spoke within their own field of expertise). Default response is the profile + lifetime stats."New value: +"Optional response sections: 'appearances' (most recent episode appearances with episode/podcast slugs), 'podcasts' (per-podcast rollup of where they appear), 'suitability' (brand-suitability exposure across the podcasts they appear on), 'recommended_podcasts' (the five shows they could plausibly appear on next — shows related to the ones they have guested on, each with the venues that led there, its suitability tier, latest episode and chart breadth; shows they appeared on, same-host sibling feeds, dormant and UNSAFE shows are already left out; the pitch list), 'in_field_appearances' (most recent appearances where they spoke within their own field of expertise). Default response is the profile + lifetime stats."

Changed2 schema fields changedOct 11, 2026

changedInput schema / properties / include / description

Previous value: -"Optional response sections: 'appearances' (most recent episode appearances with episode/podcast slugs), 'podcasts' (per-podcast rollup of where they appear), 'suitability' (brand-suitability exposure across the podcasts they appear on), 'recommended_podcasts' (the five shows they could plausibly appear on next — shows related to the ones they have guested on, minus those, each with the venues that led there; the pitch list). Default response is the profile + lifetime stats."New value: +"Optional response sections: 'appearances' (most recent episode appearances with episode/podcast slugs), 'podcasts' (per-podcast rollup of where they appear), 'suitability' (brand-suitability exposure across the podcasts they appear on), 'recommended_podcasts' (the five shows they could plausibly appear on next — shows related to the ones they have guested on, minus those, each with the venues that led there; the pitch list), 'in_field_appearances' (most recent appearances where they spoke within their own field of expertise). Default response is the profile + lifetime stats."

changedInput schema / properties / include / items / enum

Previous value: -[
-  "appearances",
-  "podcasts",
-  "suitability",
-  "recommended_podcasts"
-]New value: +[
+  "appearances",
+  "podcasts",
+  "suitability",
+  "recommended_podcasts",
+  "in_field_appearances"
+]

First observedSep 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark this as a safe read-only open-world tool, but the description adds meaningful behavior: default response contents, not_found semantics, recommendation filtering rules, ranking behavior, and suitability-band interpretation. Those details go 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 description is front-loaded and purpose-first, with useful routing details. It is somewhat dense and the recommended_podcasts explanation is a long run-on that restates schema details, but it contains little irrelevant content.

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 complex guest-profile tool with no output schema, the description is essentially complete: it explains default output, optional sections, special return behavior, and the related person tool. Nothing essential is missing for correct invocation.

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 already documents all three parameters. The description still adds practical meaning for the include sections, especially the pitch-list semantics and filtering of recommended_podcasts, though much of the enum documentation is repeated.

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 resource and scope: a guest's podcast-appearance profile with lifetime stats and frequent podcasts. It explicitly distinguishes this from particle_person_get's biographical profile and notes the not_found case for non-guests.

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?

Tells the agent when to use this tool and when to switch to particle_person_get for people with no podcast appearances. It also explains the purpose of each optional include section, including when to ask for recommendations or in-field appearances.

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?