Bullhorn MCP Agent

Overview Schema Source Related Servers Discussions Admin

list_candidates

Filter and retrieve Bullhorn CRM candidates using Lucene queries, statuses, field selections, and result limits; returns candidate data as a JSON array.

Instructions

List and filter candidates from Bullhorn CRM.

Args: query: Lucene search query (e.g., "lastName:Smith" or "skillSet:Python") status: Filter by candidate status limit: Maximum number of results (1-500, default 20) fields: Comma-separated fields to return

Returns: JSON array of candidates

Examples: - list_candidates() - Get recent candidates - list_candidates(query="skillSet:Python") - Find Python developers - list_candidates(query="lastName:Smith AND status:Active") - list_candidates(status="Active", limit=50)

Input Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`fields`	No
`status`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 15, 2026

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description must fully disclose behavior. It states returns a JSON array and explains parameters, but lacks details on pagination, sorting, error handling, or response size limits beyond the implied limit param. The examples help but do not cover all behavioral traits.

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 well-structured with a summary, Args, Returns, and Examples sections. It is concise yet informative, using bullet points and code examples to aid comprehension without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all parameters, return type, and usage patterns with examples. However, it omits details on error conditions, authentication requirements, or data freshness. Given moderate complexity and presence of an output schema, it is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It defines each parameter with usage: query includes Lucene syntax examples, status is a filter, limit has range and default, fields describes comma-separated selection. This fully explains semantics beyond 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?

The description clearly states the tool's purpose: 'List and filter candidates from Bullhorn CRM.' It specifies the action (list/filter), the resource (candidates), and the source. This distinguishes it from sibling tools like get_candidate (single candidate) and list_jobs (different entity).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes parameter explanations and four usage examples, giving clear context for typical use cases. However, it does not explicitly state when to use this tool vs. alternatives (e.g., 'use get_candidate for a single candidate'), leaving some ambiguity.

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