particle-pro

Particle Person Resolve

particle_person_resolve

Read-only

Resolve a person by free-text name. Returns ranked candidates with the canonical person slug — the stable handle accepted by particle_person_get, by every person_slug parameter (particle_podcast_find_mentions, particle_podcast_search_transcripts, particle_podcast_list_episodes), and by particle_podcast_get_guest's guest_slug.

For bulk resolution, pass a comma-separated query — each name resolves independently in one call.

For organizations, places, or mixed/unknown entity kinds use particle_entity_resolve; for companies with a known ticker or domain use particle_company_resolve.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "particle_person_resolve"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum candidates per query (1-10, default 5).
`query`	Yes	Free-text person name (e.g. 'sam altman'). Case-insensitive. Comma-separated for bulk lookup — each name is resolved independently and grouped in the response.
`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.7/5.0

Behavior4/5

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

Annotations already declare readOnly/openWorld/non-destructive, so safety is covered. The description adds genuine context beyond them: that the output is a ranked candidate list rather than a single resolution, that the slug is a stable handle accepted by several named tools, and that bulk queries resolve independently and are grouped. It stops short of noting ambiguity/failure cases (e.g. what happens when nothing matches), which keeps it off a 5.

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?

Three sentences, no filler, each doing distinct work: what it returns, the bulk mode, and the disambiguation from siblings. The routing information is last, after the core behavior is front-loaded.

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 three-parameter read-only resolver with no output schema, the description covers result shape (ranked candidates + slug), bulk behavior, and sibling disambiguation. Nothing needed to call it correctly is missing.

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 contributes meaning the schema does not: that the slug returned is the value to pass into person_slug and guest_slug parameters, and that comma-separated queries are resolved independently and grouped. The limit and output_format semantics are left entirely to the schema.

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 ('Resolve a person by free-text name') and immediately names the return shape: ranked candidates with the canonical person slug. It also distinguishes itself from particle_entity_resolve and particle_company_resolve by entity kind, so an agent can pick it without opening any schema.

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 routing rules: use this for persons, particle_entity_resolve for orgs/places/mixed, particle_company_resolve for companies with known ticker or domain. It also names the bulk pattern (comma-separated query) and the downstream tools that consume the returned slug.

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?