Skip to main content
Glama

Particle Expertise Resolve

particle_expertise_resolve
Read-only

Turn free text into the occupation and field-of-research codes the speaker-expertise filters take. When a question restricts who is speaking by occupation, profession, credentials or industry ("doctors", "medical professionals", "economists", "people in finance", "lawyers"), the filters, not search wording, decide who speaks. guest_occupation takes the everyday word itself, so the first search can carry it without waiting for this tool: call it to see or choose among the codes, and when a filter returns unresolved_reference, then retry with the code. Codes are SOC 2018 occupations (with their ISCO-08 equivalents) and ANZSRC 2020 fields of research. 'cardiologist' finds SOC 29-1212 Cardiologists; 'finance' finds the finance fields. Each code comes back with its slug, level, parent and the parameters that accept it: occupation/field on particle_podcast_list_guests and particle_expertise_get, and guest_occupation/guest_field on particle_podcast_find_mentions, particle_podcast_list_episodes, particle_podcast_search_transcripts, particle_podcast_get_episode_timeseries and particle_podcast_resolve. Pass parent to walk the hierarchy one level down (a SOC major group's minor groups, then broad groups, then occupations; a division's groups); a group such as physicians or an everyday name such as doctors filters everything below it. A word no occupation names may name a field (oncologists finds field 3211 Oncology) or a capacity: founders comes back as the capacity executive_founder, which capacity on particle_podcast_list_guests and guest_capacity on the episode and mention tools take.

Not for people or companies — use particle_person_resolve, particle_company_resolve or particle_entity_resolve. Not the topic taxonomy either: particle_topic_browse classifies what episodes are about, these codes classify what speakers know.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum codes to return (1-25, default 5).
queryNoFree text naming an occupation or a field of research (e.g. 'cardiologist', 'financial analyst', 'constitutional law'). Singular or plural; words match by prefix. Omit with parent to list that code's children, or omit both to list the top level.
parentNoA code, slug or title whose children to list (e.g. '29-0000' for the healthcare occupations, or '38' for economics). With query, searches only below it.
standardNoWhich codes to search: 'occupation' (SOC 2018, with ISCO-08 equivalents), 'field' (ANZSRC 2020 fields of research), or 'any' (default) for both.
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. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the read-only/non-destructive annotations, the description discloses the code systems in use (SOC 2018, ISCO-08, ANZSRC 2020), the returned fields per code, hierarchy traversal behavior, and the fallback to capacities such as `executive_founder`. This is substantial behavioral context for a resolver tool with no output schema.

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 purpose and usage guidance are front-loaded, and the dense content is largely relevant for a complex resolver. It is long and includes a lengthy cross-tool parameter list, but almost every sentence carries actionable information.

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?

There is no output schema, but the description explains the return structure at a useful level: each code comes with slug, level, parent, and the parameters that accept it. Combined with the annotations and the detailed schema, an agent has enough information to select, call, and chain this tool correctly.

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 already 100%, so parameter documentation is strong. The description still adds useful semantics beyond the schema, especially for `parent`: walking the SOC/ANZSRC hierarchy one level down, and the fact that a group or everyday name filters everything below it.

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 precise verb and resource: 'Turn free text into the occupation and field-of-research codes the speaker-expertise filters take.' It explicitly distinguishes this resolver from person/company/entity resolvers and from the topic taxonomy, so an agent can identify its role without opening the 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?

It gives clear when-to-use guidance: questions that restrict speakers by occupation, profession, credentials or industry. It also explains when this tool is optional, when to retry after an `unresolved_reference`, and names the sibling resolvers to use instead for people, companies, or entities.

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