Search people and companies, enrich profiles, and find email and phone over MCP.
Scored across 11 tools
Most tools target clearly distinct resources (account, billing, lists, filters, guide, candidates, job status). The main overlap is between resolve_area and resolve_location, which both return location IDs, though their descriptions differentiate radius-based vs. free-text resolution.
Every tool follows a consistent snake_case verb_noun pattern (check_, get_, list_, resolve_). There are no naming style deviations or vague tool names.
With 11 tools, the set is well-scoped and each tool appears to earn its place for the recruitment/account domain. The count sits comfortably within the typical 3–15 range.
Core recruitment workflows are missing: there is no tool to perform a people search, start an enrich_profiles job, or create/update lists, even though the descriptions reference search and enrichment. These gaps would cause clear agent dead ends.
Free. For each person (profile_url, profile_id, or full_name with current_employer), whether they are in the seen register and with which status, in input order.
| Name | Required | Description | Default |
|---|---|---|---|
| identities | Yes | People to check, in the order to return. |
| Name | Required | Description |
|---|---|---|
| cost | No | |
| data | No | |
| has_more | No | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value: cost ("Free") and the guarantee that results come back "in input order," plus the fact that a status is returned per person.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the cost cue front-loaded, followed immediately by the operation and its input/output contract. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return format need not be explained, and the description still notes the returned status and ordering. What's missing is only minor: no note on behavior for unmatched people or rate/limit context beyond "Free."
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four identity fields and their matching rules. The description restates the identifier alternatives and implicitly notes max-of-one-person-per-entry, adding little beyond the structured schema — baseline 3 is right.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (check) and resource (the seen register), and spells out the identity forms accepted so an agent knows exactly what input qualifies. No sibling (billing, lists, guides, resolve_*) overlaps this register-lookup purpose, so it is unambiguously distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Free" signals a zero-cost call an agent can use liberally, and the ordering contract implies batch-style usage. However, it never states when to reach for this tool versus not doing so, nor any prerequisites (e.g. registration expectations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Balance by source, next expiries, spend over the last 30 days by purpose, the key's scopes and daily cap, and the selected customer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| cost | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description's useful addition is 'Free', a cost signal not in the annotations, but it says nothing about auth requirements, rate limits, or scoping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the cost signal and then lists contents in priority order with no filler. It is a noun-phrase fragment rather than a sentence, but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation in the description is a bonus rather than a requirement, and it usefully previews the payload shape. With no parameters and full annotation coverage, the remaining gap is purely the absence of when-to-use routing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly spends no words on inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name plus the enumerated contents (balance by source, expiries, 30-day spend by purpose, key scopes/cap, selected customer) make it unambiguous what this tool retrieves. It doesn't explicitly differentiate itself from siblings like list_billing_transactions or get_auto_refill, leaving some overlap to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to call this versus alternatives; the sibling set contains several finance-adjacent tools (list_billing_transactions, get_auto_refill) with no routing guidance. 'Free' is a weak cost hint toward using it liberally but is not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Whether auto-refill is on, the balance threshold, the monthly caps, and whether a card is on file. Account keys only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| cost | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds two pieces of behavior the annotations do not carry: the call is free (no billing impact) and it requires an account-scoped key. That is genuine added context, though nothing is said about scope limits or freshness of the returned values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short fragments, each load-bearing: cost, returned fields, auth requirement. The most decision-relevant constraint ('Free') is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be documented, so the enumeration of fields is a bonus rather than a requirement. For a zero-parameter read tool with full annotation coverage, the description plus 'Account keys only' is nearly sufficient; only the when-to-use routing to siblings is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics to compensate for. The description correctly spends no words on arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource (auto-refill settings) and enumerates the specific fields returned: on/off state, balance threshold, monthly caps, and card-on-file status. The verb 'get' is carried by the name, and the resource is distinct from billing siblings like list_billing_transactions, though no sibling is explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Account keys only' and 'Free' give two call prerequisites (auth scope, no billing cost), which is more than nothing. However, there is no statement of when to reach for this tool versus get_account_overview or list_billing_transactions, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Rules, prices, recipes, and filters. Read overview before the first search and costs before spending.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | overview is the default. |
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| topic | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, destructiveHint and openWorldHint, so the safety profile is fully handled by structured data. The description adds one genuinely new behavioral fact — 'Free' — meaning no billing consequence, which is useful but is the only addition beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments, no filler, with the cost note and the usage rule front-loaded. It is efficient, though the middle noun list is a little unparsed and could have been tied to the topic values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter, read-only documentation tool with a full output schema and rich annotations, the description covers what it is, its cost, and when to consult it. Nothing essential to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the enum's default is already documented in the schema ('overview is the default'). The phrase 'Rules, prices, recipes, and filters' loosely maps to some topic values but does not add syntax, format, or selection guidance beyond what the enum already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (the guide) and enumerates its contents — rules, prices, recipes, filters — which tells an agent what it will get back. The verb 'read' is only implicit and the framing is telegraphic, but the topic enumeration clearly separates it from siblings like get_list or list_billing_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit sequencing guidance: 'Read overview before the first search and costs before spending.' That tells the agent when in a workflow to call this. It stops short of naming alternative tools or stating when not to call it, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. A list and a page of its people. format csv returns the whole list as CSV text, not a JSON string.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many items to return. Default 25, at most 100. | |
| cursor | No | next_cursor from the previous response. | |
| format | No | json returns a page of items. csv returns the whole list as CSV text. | |
| list_id | Yes | List id from save_to_list or list_lists. |
| Name | Required | Description |
|---|---|---|
| cost | No | |
| data | No | |
| has_more | No | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds two genuinely useful behavioral facts beyond that: the call is free, and format=csv returns raw CSV text rather than a JSON string; however it says nothing about pagination limits under the json path beyond what the schema states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short fragments with no waste and the cost signal front-loaded. The phrasing is telegraphic and slightly ungrammatical ('A list and a page of its people'), which costs a little clarity but keeps it tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, rich annotations and fully documented parameters, the description only needs to fill behavioral gaps, which it partly does (free, CSV not JSON-wrapped). It omits how csv interacts with limit/cursor and any permission or scoping prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents list_id, limit, cursor and format including the default of 25 and max of 100. The description reinforces the format semantics and adds the 'not a JSON string' encoding nuance, but adds little else beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description conveys the resource (a list plus a page of its people), which is more than a tautology, but it is a verbless noun phrase ('A list and a page of its people') rather than a stated action. It does not differentiate itself from the sibling list_lists, which an agent must infer returns the collection of lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, and no sibling is named as an alternative (list_lists only appears in the schema, not the description). The word 'Free' is a cost signal but not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Status of an enrich_profiles job. wait_seconds waits up to 25 seconds for it to finish. When completed, data holds the profiles.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | compact is the short profile. full is every stored field, including education. Default full. | |
| job_id | Yes | Job id from enrich_profiles. | |
| wait_seconds | No | Seconds to wait for completion before returning. Maximum 25. Default 0. |
| Name | Required | Description |
|---|---|---|
| cost | No | |
| data | No | |
| has_more | No | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered; the description still adds real context the annotations do not carry — that the call is free, that it can long-poll up to 25 seconds, and that `data` is populated only once the job completes. It stops short of describing failure/partial job states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short, front-loaded sentences that lead with the most decision-relevant facts (cost, what it returns, polling behavior) and waste little. The 'wait_seconds waits up to 25 seconds' clause restates the schema, a minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be enumerated, and annotations cover the safety profile; the description supplies the missing operational context (cost, long-poll, completion semantics). Only the handling of unfinished or failed jobs is left unaddressed for a simple 3-parameter reader.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so `view`, `job_id`, and `wait_seconds` are already fully documented, including the 25-second cap. The description's note about `wait_seconds` duplicates the schema rather than adding format or edge-case meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: retrieves the status of an `enrich_profiles` job, and adds that completed jobs carry profiles in `data`. It is clearly distinct from the sibling tools, none of which deal with async job polling, though it does not explicitly name the producing tool as a routing cue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: mentioning the job is an `enrich_profiles` job and that `wait_seconds` waits for completion telegraphs the poll-after-enrich pattern, and 'Free' hints at cost. But there is no explicit when-to-use, no guidance on the non-blocking (wait_seconds=0) vs long-poll choice, and no reference to the tool that starts the job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Credit grants, purchases, usage, and expiries, newest first. Pass next_cursor as cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Only rows of this kind. | |
| limit | No | How many items to return. Default 25, at most 100. | |
| cursor | No | next_cursor from the previous response. |
| Name | Required | Description |
|---|---|---|
| cost | No | |
| data | No | |
| has_more | No | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only, idempotent, non-destructive profile, so the bar is lower. The description adds genuinely non-structured context: that the call is free, that rows come back newest-first, and how to page forward. It does not mention rate limits or retention windows, but that is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short fragments, no filler, and the cost and content are front-loaded. It is telegraphic to the point of omitting the verb, but nothing in it is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape need not be described, and the three parameters are fully specified in the schema. Ordering and pagination behavior are covered; only explicit when-to-use guidance is absent, which is minor for an unfiltered listing endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so kind/limit/cursor are already documented in the schema, including the enum values and the 25/100 default. 'Pass next_cursor as cursor' mostly restates the cursor parameter's own schema description, adding little beyond it; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the resource content precisely (credit grants, purchases, usage, expiries) so an agent knows this is the billing ledger listing. The verb is only implied by the tool name, and no sibling is named, but the sibling set (accounts, lists, locations) is far enough away that disambiguation is not needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Free.' signals there is no cost barrier to calling it, which is a mild usage cue, but the description never states when to use this tool versus something else, nor any prerequisites. Usage is only implied by the content listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Ids for industries, seniorities, experience ranges, functions, profile languages, and company headcounts.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Only values whose label contains this text. Same as the REST q query. | |
| kind | Yes | industries, seniorities, experience_ranges, functions, languages, or headcounts. |
| Name | Required | Description |
|---|---|---|
| cost | No | |
| data | No | |
| has_more | No | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and non-open-world, so the safety profile is covered. The description adds one genuinely new behavioral fact — that the call is free — but says nothing about result size, pagination, or whether values are global or account-specific. With annotations carrying the safety burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is very short and front-loads the 'Free' cost signal, which is good structure. However, the remainder is a bare list that duplicates the schema enum, so the sentence exists mainly to repeat structured data rather than earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the tool is simple (2 params, 1 enum). Still, for a reference-data lookup the description omits how the IDs are meant to be used downstream and whether the returned set is stable, leaving it only minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both params (q and kind) are already documented in the schema, including the 'same as the REST q query' note. The description's enumeration of kinds duplicates the enum rather than adding syntax or semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates the resource categories (industries, seniorities, experience ranges, functions, languages, headcounts) but never states the action — it relies on the title for the verb 'list' and largely re-states the schema enum. It gives no differentiation from sibling lookup tools such as resolve_area or resolve_location, so the purpose is inferable but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is the word 'Free,' which hints that this lookup costs no credits. There is no statement of when to call it versus the resolve_* siblings, no mention that the returned IDs feed other tools' filter parameters, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Lists in this workspace with their size.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many items to return. Default 25, at most 100. | |
| cursor | No | next_cursor from the previous response. |
| Name | Required | Description |
|---|---|---|
| cost | No | |
| data | No | |
| has_more | No | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description does add two non-schema facts: the call is free and each entry carries a size, but it says nothing about pagination limits or what the size unit means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two terse fragments with no padding, and the unusual-but-relevant cost attribute leads. It is slightly under-specified rather than verbose, but nothing in it is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, rich annotations, and full parameter documentation, the description only needs to establish purpose and routing, and it establishes purpose only minimally. It omits any mention of the default/maximum page size or how to continue paging, and gives no signal to distinguish it from the sibling get_list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – both 'limit' (1–100, default 25) and 'cursor' are fully documented in the schema itself. The description adds no syntax, format, or meaning beyond that, so it sits at the baseline for a fully documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The fragment 'Lists in this workspace with their size' names the resource (lists) and hints at the returned field (size), so the intent is inferable, but no explicit verb is used and it does nothing to separate itself from the sibling get_list, which an agent could easily confuse for enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Free' signals that calls are not billed or quota-limited, which is useful context, but there is no statement of when to call this versus alternatives such as get_list or list_filter_values, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Anchor places and radius_km become at most 12 location ids. Under 20 km only the anchor city is used. The search index has no radius: pass geo_ids as the location filter.
| Name | Required | Description | Default |
|---|---|---|---|
| anchors | Yes | Anchor places. Same as GET /v1/lookups/areas anchors. | |
| radius_km | No | Kilometres around the anchors. Default 30. Under 20 stays on the anchor city. |
| Name | Required | Description |
|---|---|---|
| cost | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the description is not carrying the safety burden. It nonetheless adds real behavioral facts beyond them: the call is free, results are capped at 12 ids, and a radius under 20 km collapses to the anchor city only. It stops short of describing failure modes or truncation edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no padding, each carrying information. The only structural nit is that 'Free.' leads ahead of the purpose statement, so the first thing an agent reads is a cost note rather than what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description supplies cost, result caps, radius semantics and a downstream integration hint. It is nearly complete for a 2-parameter tool; only sibling differentiation and error behavior are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes further by explaining what the parameters produce ('anchors and radius_km become at most 12 location ids') and how the radius is consumed by the index, which is not derivable from the schema alone. 'Under 20 km only the anchor city is used' partially repeats the schema's radius description, slightly diluting the added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete transformation: anchors plus radius_km are resolved into at most 12 location ids. That is a specific verb+resource an agent can act on. It does not, however, distinguish itself explicitly from the sibling resolve_location, leaving the agent to infer the area-vs-single-location split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: 'The search index has no radius: pass geo_ids as the location filter' tells the agent what to do with the result downstream, and 'Free' signals a cost consideration. There is no explicit when-to-use-this-vs-alternatives guidance (e.g. versus resolve_location or check_candidates).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Free text to numeric location ids for people search, including a place this server has not seen before. "UK" is the United Kingdom. prefer_area returns the metropolitan area for radius searches. This call never charges.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Alias of text. Same name as GET /v1/lookups/locations?q=. | |
| text | No | Place name, for example Amsterdam or Berlin. Same as REST q. Send text or q. | |
| country | No | Country name appended to text, for example Netherlands. | |
| prefer_area | No | When true, prefer the metropolitan area id used for a radius search. |
| Name | Required | Description |
|---|---|---|
| cost | No | |
| data | No | |
| has_more | No | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is covered; the description adds two things they do not: that the call is free / never charges, and that it will resolve places this server has not seen before. That cost and coverage context is genuinely useful. It does not address rate limits or lookup failure behavior, keeping it short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is short, but it is delivered as choppy fragments and states the free-of-charge fact twice ('Free.' and 'This call never charges.'), which is a wasted sentence. Front-loading of the core purpose is good, but the redundant cost line costs it a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and annotations cover the safety profile. Combined with cost transparency and the unknown-place behavior, an agent has enough to call this correctly; only the relationship to resolve_area is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so q/text/country/prefer_area are already documented in the schema; baseline is 3. The description adds a small amount of meaning for prefer_area (metropolitan area for radius searches) and an example ('UK' means the United Kingdom), but does not explain the q/text aliasing or how country is combined with text beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: converts free text into numeric location ids for people search, and notes it works even for places the server has not seen before. That distinguishes it from list-style siblings, but it never names its closest sibling resolve_area or explains the division of labor, so sibling differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives one piece of conditional guidance — set prefer_area when the caller needs the metropolitan area for a radius search — and notes the call is free, which affects whether to use it liberally. However there is no explicit when-to-use / when-not-to-use against resolve_area or check_candidates, so guidance stays implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_candidates1 field changedInput schema / properties / identities / items / properties / profile_id / descriptionPrevious value: -"Search id or the other member id. Either matches the same person."New value: +"Search id or the other profile id. Either matches the same person."check_candidatesget_account_overviewget_auto_refillget_guideget_listget_people_joblist_billing_transactionslist_filter_valueslist_listsresolve_arearesolve_locationFind verified B2B emails and phone numbers; search and enrich people and companies for prospecting.
Find companies and B2B contacts, enrich profiles, and look up work emails and business phones.
RocketReach MCP — wraps the RocketReach person-lookup API (rocketreach.co)
Real-time B2B professional profiles, company intelligence & jobs hosted MCP. OAuth or API key.
Add one secure layer between your agents and this server.