Live LinkedIn people, company, post and job data, ICP search and job-change signals for AI agents.
Scored across 18 tools
Each tool targets a distinct resource+action (get_person_profile vs get_person_activity vs get_post vs get_post_engagement are clearly separated), and the signal tools have non-overlapping roles. The only real friction is between list_filter_values (free, all enumerated values) and suggest_filter_values (paid, one specific value), which an agent could plausibly mispick despite the descriptions.
All 18 tools follow a consistent verb_noun snake_case pattern: check_*, create_*, get_*, list_*, search_*, suggest_*, update_*, delete_*. No mixed conventions or vague verbs.
18 tools is slightly above the comfortable 3-15 band but justified by the breadth of the surface: people, companies, jobs, posts, engagement, signals (5 tools), filter discovery, and credits. Each tool earns its place and none appear redundant.
Core enrichment and ICP search workflows are well covered, and signals have full create/update/delete/list lifecycle. However, there is no job search tool (only get_job_details by id/URL), and list_signal_leads explicitly covers only the four engagement signal types—leads from job_change, new_post, and person_activity monitors are only deliverable by email/webhook, leaving an agent-facing gap.
Get the current Datamagnet credit balance: remaining, total and used.
Free, and fast. Worth calling before a run that will make many paid calls, and worth calling again if a tool reports running out. Every other tool except the signal tools spends credits, so this is how you find out whether a plan is affordable before starting it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent and openWorld; the description adds cost ('Free, and fast') and the crucial economic context that all other non-signal tools consume credits. That's real value beyond structured fields, though it doesn't discuss whether the balance is workspace-scoped or cached/staleness.
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?
What it returns leads, then cost/latency, then the decision guidance. Every sentence earns its place — no filler, no restating the title verbatim.
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 needn't be explained, yet the description still names the three figures. For a trivial 0-param tool the description gives everything an agent needs: cost, latency, and when to interleave calls.
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 baseline 4 applies; the description correctly doesn't waste words on inputs and instead explains what the (absent) parameters don't scope, i.e. a single global balance.
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 ('Get the current Datamagnet credit balance') and enumerates the returned fields (remaining, total, used). It's clearly distinguishable from every sibling, which are all search/get-profile/signal tools.
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?
Explicit when-to-use: before a run making many paid calls, and again after a tool reports running out. It also names the exception set ('every other tool except the signal tools spends credits'), which routes the agent correctly against the 18 siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a standing monitor that notifies the account when something happens on LinkedIn. Free to create.
What each type watches:
job_change — tracked people changing job or company
new_post — tracked people publishing a new post
person_activity — tracked people reacting to or commenting on any
post, anyone's: their own engagement, reported one item at a time
keyword_engagement — people engaging with posts matching keywords
industry_engagement — people engaging with posts from an industry
company_engagement — people engaging with specific companies' posts
person_engagement — people engaging with specific people's posts
(the reverse of person_activity)
job_change, new_post and person_activity require profile_urls.
An account can run several of one type (say "Champions" and "Churned
customers"), each with its own signal_id. Without signal_id, a create
adds the profiles to the account's only signal of that type, or starts
one if there is none. Pass signal_id to add to a specific signal, or
new_signal: true to start another. With several and neither given,
the call fails: find the right one with list_signals. Adding to a
signal keeps its name and settings; if it is paused, resume it first.
name is an optional display label for a new signal. It can repeat
and can be changed later with update_signal action rename.
person_activity takes an optional activity_types: reactions,
comments, or both (the default). Each costs one lookup per profile per
run, so asking for one halves the cost. It applies when the monitor is
first created; on an existing monitor change it with update_signal
action update_activity_types. The first run records a baseline and
reports nothing; after that every new reaction, comment and reply is
reported once.
keyword_engagement requires keywords, and takes an optional icp
object to filter and score the leads it surfaces. Several of these can
coexist; each gets its own signal_id.
Notifications go to the account email. additional_emails adds more
recipients. webhook_url receives a POST when the signal fires, signed
with webhook_secret if one is given.
| Name | Required | Description | Default |
|---|---|---|---|
| icp | No | ||
| name | No | ||
| keywords | No | ||
| signal_id | No | ||
| new_signal | No | ||
| signal_type | Yes | ||
| webhook_url | No | ||
| profile_urls | No | ||
| activity_types | No | ||
| webhook_secret | No | ||
| additional_emails | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond annotations: free creation, notification routing to account email, additional recipients, signed webhooks, per-run lookup costs, and baseline behavior on first run. It also explains that adding profiles preserves existing signal name/settings.
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 description is long but dense and largely front-loaded, with no obvious filler. The type list and multi-paragraph rules are appropriate for an 11-parameter tool, though the density could be organized slightly more crisply.
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?
Given seven signal types, 11 parameters, and an output schema, the description covers the essential creation workflows, notification behavior, update handoff, and failure conditions. The main remaining gap, icp internals, is a minor detail rather than a missing operational requirement.
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?
With 0% schema description coverage, the description carries most parameter meaning: it explains signal_type values, required profile_urls, signal_id/new_signal semantics, activity_types cost/default, keywords, icp filtering/scoring, and notification params. It still leaves profile_urls format and icp object structure unspecified.
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: 'Create a standing monitor' for LinkedIn activity. It immediately distinguishes the tool from siblings by explaining signal types and linking lifecycle actions to list_signals and update_signal.
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?
Explicitly covers when signal_id, new_signal, and neither should be used, including the failure mode when multiple signals exist. It also states prerequisites like profile_urls for certain types, keyword requirements, and the need to resume a paused signal before adding to it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a signal monitor and everything it has collected. Free, and irreversible.
This cannot be undone. If the user might want the monitor back, call
update_signal with action pause instead.
For the four engagement types, signal_id deletes that one signal;
omitting it deletes every signal of that type on the account, which is
rarely what someone means. For job_change, new_post and
person_activity, signal_id deletes that one signal; it can be left
out only when the account has a single signal of that type.
| Name | Required | Description | Default |
|---|---|---|---|
| signal_id | No | ||
| signal_type | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this as destructive and non-idempotent, and the description adds important context beyond them: the deletion is permanent, irreversible, free, and removes everything the monitor collected. It also warns that omitting signal_id may delete all signals of a type.
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 description is front-loaded with the destructive nature and the safer alternative, then follows with the parameter caveats. The repetition of irreversibility is justified for a destructive operation and does not obscure the key instructions.
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?
Given that an output schema and annotations exist, the description supplies all the extra behavioral and parameter context an agent needs to invoke this destructive tool correctly. Nothing essential 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 0%, so the description carries the full burden. It does so well by explaining the conditional meaning of signal_id for engagement versus job_change/new_post/person_activity signal types and the consequences of omitting it.
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 specific verb and resource: permanently delete a signal monitor and all collected data. It clearly distinguishes this from the safer alternative by naming update_signal with action pause.
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 explicitly tells the agent when to use this tool versus the alternative: if the user might want the monitor back, use update_signal pause instead. It also explains the dangerous omission behavior for signal_id across signal types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a company's Crunchbase funding history by domain: amount raised, round type and announcement date for each round.
Costs 5 credits. Takes a web domain such as stripe.com, not a
LinkedIn URL. company_name is optional and only helps disambiguate
when the domain is shared or ambiguous.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| company_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, so safety is covered. The description adds genuinely non-structured context: the call "costs 5 credits" — the single most important operational fact for an agent deciding whether to call it. It stops short of noting data freshness or rate limits.
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: what it returns first, then cost, then input format and parameter guidance. Every sentence carries information an agent needs, with 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?
Output schema exists so return shape needn't be described; cost, input format, and the optional-parameter rationale are all present. Only gaps are data recency and how to choose this over sibling company tools.
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 0%, so the description must carry the load, and it does: domain is constrained to a bare web domain with a concrete example and an explicit anti-pattern (LinkedIn URL), and company_name's purpose (disambiguation when the domain is shared or ambiguous) is spelled out. Both of the two parameters gain meaning not present in the 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?
States a specific verb and resource ("Fetch a company's Crunchbase funding history by domain") and enumerates the returned fields (amount raised, round type, announcement date). It is distinguishable from get_company_profile by scope, but the description never names that sibling to make the boundary explicit.
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 the concrete input format constraint ("Takes a web domain such as `stripe.com`, not a LinkedIn URL") and explains when to bother with the optional company_name. It does not, however, say when to prefer this over search_companies or get_company_profile for company data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch posts published on a LinkedIn company page, with text, media, engagement counts and timestamps.
Costs 10 credits per call. Paginated by cursor — pass the cursor from the previous response for the next page, and expect to be charged again for it.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| type | No | ||
| cursor | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important operational behavior: a 10-credit cost per call, cursor-based pagination, and the fact that fetching the next page incurs another charge. These are material details an agent would not know from annotations alone.
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 description is compact and front-loaded: purpose first, then cost, then pagination behavior. Every sentence adds useful information without repetition.
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?
Given the output schema and annotations already cover return shape and safety profile, the description does enough by explaining cost and pagination. The main remaining gap is the unexplained 'type' parameter.
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 0%, so the description must compensate. It explains the cursor parameter well and implies that the URL is a company-page URL, but it does not explain the 'type' parameter or its enum values (all/articles/documents).
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 uses a specific verb and resource: fetch posts published on a LinkedIn company page. It clearly distinguishes this from a single-post or profile tool by scoping the resource to company-page posts, though it does not explicitly name a sibling alternative.
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 intended use is implied by 'LinkedIn company page,' and pagination guidance is given for cursor usage. However, the description does not explicitly state when to use this tool versus siblings like get_post, get_post_engagement, or get_company_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a LinkedIn company's profile: name, industry, headcount, headquarters, specialties and recent updates.
Costs 1 credit. The two enrichment flags are expensive and are only
charged when they succeed: company_insights adds 10 credits and
get_funding_rounds adds 5. Turn them on only when asked for.
If you want funding history alone, get_company_funding_rounds is cheaper than turning the flag on here.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| lang | No | ||
| use_cache | No | ||
| company_insights | No | ||
| get_funding_rounds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld/idempotent annotations by disclosing the billing model: 1 base credit, +10 for company_insights, +5 for get_funding_rounds, and the non-obvious detail that enrichment charges only apply on success. That is exactly the cost/risk context an agent needs before opting into paid flags.
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 paragraphs, front-loaded with what the tool returns, then cost, then the alternative. Every sentence carries information; only the line-broken formatting slightly weakens the front-loading.
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 and annotations already covering safety and return shape, the description only needed to add cost and routing semantics, which it does. The remaining gap is cache and language behavior, which matters for idempotency expectations but is a second-order concern here.
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 0% across five parameters, so the description must carry the load. It does well for the two expensive flags (naming their credit prices), but leaves `lang` and especially the `use_cache` enum ('if-present'/'if-recent'/'never') completely unexplained, which is the parameter most likely to be misused.
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 ('Fetch a LinkedIn company's profile') and enumerates the returned fields (name, industry, headcount, headquarters, specialties, recent updates). It also names the sibling it is not (get_company_funding_rounds), so the agent can distinguish it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit conditional guidance: 'Turn them on only when asked for' for the expensive flags, plus a concrete routing rule — if funding history alone is needed, use get_company_funding_rounds because it is cheaper. That is when-to-use, when-not-to-use and the alternative all in one place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one LinkedIn job posting: title, description, location, seniority, employment and workplace type, apply links, application counts and the hiring company.
Costs 1 credit. include_hiring_team adds 1 more, charged only when
the hiring team is actually returned.
Give either job_id (the numeric id) or url (any LinkedIn job URL —
the id is extracted for you). One of the two is required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| job_id | No | ||
| include_hiring_team | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real cost behavior beyond the annotations: base cost of 1 credit, plus 1 for `include_hiring_team` charged only when the hiring team is actually returned. Annotations already cover read-only/idempotent/open-world semantics, so this is a meaningful addition. It doesn't describe failure behavior for invalid ids or URLs.
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, front-loaded blocks: content returned, cost model, argument contract. No filler sentences, and the critical cost/argument constraints appear before any detail.
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 is not required, and the description covers cost and the required-argument constraint. Minor gaps remain around invalid-input behavior and the schema typing of `job_id` as a string despite being called numeric.
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 0%, so the description must compensate, and it does: `job_id` is the numeric id, `url` accepts any LinkedIn job URL with the id extracted automatically, and `include_hiring_team` toggles an optional extra-cost payload. All three parameters are given meaning absent from the 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?
States a specific verb and resource ('Fetch one LinkedIn job posting') and enumerates the returned fields (title, description, location, seniority, employment/workplace type, apply links, application counts, hiring company). No sibling tool retrieves a single job, so the scope is unambiguous against the surrounding search/get tools.
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 clear invocation guidance: supply either `job_id` or `url`, one of the two is required. It does not state when to prefer this over a search tool (e.g., after obtaining an id from search results), but no sibling actually competes for this function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch what a LinkedIn person has recently posted, commented on, reacted to, or published as an article.
Costs 10 credits per call, so this is one of the more expensive tools.
Prefer one call over several: use type to ask for exactly the
activity you need rather than fetching everything and filtering.
Paginated by cursor. Pass the cursor from the previous response to get the next page; each page is charged again.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| type | No | ||
| cursor | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the readOnly/idempotent/openWorld annotations: the 10-credit cost per call, the warning that each paginated page is charged again, and the cursor-based pagination model. Cost and re-charge behavior are exactly the operational facts an agent cannot infer from annotations or schema.
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 sentences, front-loaded with the core operation, then cost warning, then efficiency advice, then pagination mechanics. No filler; every sentence conveys a distinct, actionable fact.
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 3-parameter read tool with an output schema already defining return values, the description covers what matters: scope, cost model, narrowing via `type`, and pagination. Only `url` format remains slightly underspecified, which is a minor gap.
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 0%, so the description must carry parameter meaning. It explains `type` well (the four activity kinds) and fully explains `cursor` (pass the previous response's cursor), but the required `url` parameter is never clarified — it is only implied by 'a LinkedIn person', leaving format/expectations unstated.
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 (fetch) and resource (a LinkedIn person's recent posts, comments, reactions, articles), enumerating the activity kinds. This cleanly separates it from siblings like get_company_posts, get_person_profile, or get_post, which operate on different entities.
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 concrete usage guidance: prefer a single call, use `type` to narrow instead of fetching everything and filtering, and pass the cursor to paginate. It does not explicitly contrast with the closest alternatives (e.g., when to use get_person_profile instead), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a LinkedIn person's profile: name, headline, current role and company, location, full experience, education and more.
Costs 1 credit. Optional enrichments add to that, and are only charged
when they succeed: each of the seven boolean interest flags adds 2
credits. Leave them off unless the user asked for what they return.
include_extra and skills are deprecated and ignored: they change
neither the data nor the price.
use_cache controls freshness. The default returns a cached profile of
any age. Use if-recent for a profile no older than 29 days, or
never to force a live fetch. Both are slower.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| lang | No | ||
| skills | No | ||
| use_cache | No | ||
| include_extra | No | ||
| group_interest | No | ||
| school_interest | No | ||
| company_interest | No | ||
| similar_profiles | No | ||
| newsletter_interest | No | ||
| top_voices_interest | No | ||
| recommendations_data | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld/idempotent annotations: discloses the 1-credit base cost, the 2-credit surcharge per interest flag, that enrichments are only charged on success, that deprecated params are ignored at no cost, and that cache-avoiding modes are slower. That is exactly the cost/latency/auth context an agent needs before invoking.
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?
Front-loads the resource and payload in one sentence, then separates cost, deprecation and caching into short paragraphs. Every sentence carries distinct information; 'and more' is the only 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?
For a 12-parameter, zero-coverage schema with an output schema present, the description covers the highest-risk details (pricing, caching freshness, deprecated params). Only 'lang' and the per-flag return semantics are left unaddressed, which is a minor omission rather than a blocking one.
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 0% across 12 parameters, so the description must carry the load, and it does explain the non-obvious ones: all three use_cache modes, the deprecation of include_extra and skills, and the pricing of the seven boolean flags. It does not describe what each individual interest flag returns, nor the 'lang' parameter, leaving residual gaps.
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?
Opens with a specific verb and resource ('Fetch a LinkedIn person's profile') and enumerates the returned fields (name, headline, role, company, location, experience, education), which clearly separates it from get_company_profile. It does not explicitly distinguish it from near-neighbours like get_person_activity or search_people, so it stops short of a 5.
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 actionable selection rules for the optional behaviour: 'Leave them off unless the user asked for what they return', and 'Use if-recent for a profile no older than 29 days, or never to force a live fetch'. It never names an alternative sibling tool or states when to prefer search_people instead, so no exclusion guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one LinkedIn post by URL: author, text, media, engagement counts and publish time.
Costs 1 credit. This returns the post itself and its totals. To get the people behind those totals, use get_post_engagement.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, and idempotent behavior, so the description adds useful context by disclosing the 1-credit cost and the returned data scope. It does not discuss auth or rate limits, but the added credit and routing information is valuable 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?
The core action and scope are front-loaded in the first sentence, followed by cost and the key alternative. There is no wasted language.
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, annotations, cost disclosure, return-field summary, and a sibling route, the definition is nearly complete for a simple post-by-URL lookup. The only notable omission is URL format guidance.
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 0%, so the description carries the burden. It adds that the input is a LinkedIn post URL rather than an ID, but gives no URL format or example, leaving a clear gap.
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: 'Fetch one LinkedIn post by URL,' and enumerates the returned fields. It also distinguishes itself from get_post_engagement by clarifying that this returns totals, not the people behind them.
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?
Explicitly routes the agent to get_post_engagement when the goal is the people behind engagement totals. The cost statement and 'one post by URL' scope make the intended use clear without leaving ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the people who engaged with a LinkedIn post, with their
profiles. kind picks which kind of engagement:
comments — commenter profiles, comment text and reply threads
reactions — who reacted and with which reaction type
reposts — who reshared it and any commentary they added
Costs 10 credits per page, so paginate deliberately. Ask for page 1 first and only go further if the user needs more than it returns.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| kind | Yes | ||
| page | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world behavior. The description adds important context beyond that: each page costs 10 credits and pagination should be deliberate, which materially affects agent behavior.
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 description is front-loaded, tightly structured, and uses bullets only where they add clarity. Every sentence contributes purpose, parameter meaning, or cost/pagination guidance.
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?
Given annotations and an output schema, the description covers the key invocation decisions: what each `kind` returns, that profiles are included, and pagination cost. Minor details such as exact URL format or auth constraints are not stated, but the core call context is complete.
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 0%, so the description must carry parameter meaning. It explains `kind` thoroughly and gives pagination guidance for `page`, while `url` is strongly implied as the LinkedIn post URL by the opening sentence.
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 specific verb and resource: fetch the people who engaged with a LinkedIn post, including their profiles. The three engagement kinds make the scope unambiguous and distinguish it from post-content or profile-only siblings.
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 clear operational guidance for choosing a `kind` and for pagination: start with page 1 and only continue if the user needs more. It does not name an alternative sibling tool or when-not to use this one, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get every valid value for the ICP search filters — industries, seniorities, functions, headcount bands and the rest.
Free. Call this when unsure whether a filter value will be accepted, rather than guessing and spending 10 credits on a search that returns nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety and repeatability are covered. The description adds genuinely non-structured context: the call is free while a bad filter costs 10 credits and returns nothing, which is exactly the kind of cost/failure-mode signal an agent needs for planning. It doesn't describe output shape, but an output schema exists so that burden is lifted.
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 sentences, front-loaded with the outcome and then the decision rule and cost rationale. Every clause earns its place — the 'Free' stipend and the 10-credit penalty are the two facts that drive correct usage.
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 no parameters, an output schema, and safety annotations, the description covers everything needed to invoke it correctly and cheaply. The only missing piece is how this differs from suggest_filter_values, which a sibling-aware agent would want spelled out.
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 there is nothing to disambiguate, and the description corroborates the no-arg model by framing it as a bulk catalog lookup rather than a query. Baseline 4 applies for a 0-param tool.
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 ('Get every valid value for the ICP search filters') and enumerates the filter families covered, so the agent knows exactly what it returns. However, it never distinguishes itself from the sibling suggest_filter_values, which by name appears to address the same need — that ambiguity is left for the agent to resolve.
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 a clear trigger ('call this when unsure whether a filter value will be accepted') and contrasts it against the costly alternative behavior of guessing and burning 10 credits on a search. It stops short of naming suggest_filter_values as the sibling to prefer in any scenario, so one routing decision is unresolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the leads this account's engagement signals (keyword_engagement, industry_engagement, company_engagement, person_engagement) have found. Free. The leads are always this account's own, from the caller's key; there is no way to fetch another account's leads.
Every argument is optional and narrows the result. With none, this returns the 50 most recent leads across every signal, newest first.
signal_id scopes to one signal — get it from list_signals; omitting
it searches all of them. min_score / max_score filter the 1-3 lead
score. keyword matches signal_keyword exactly, case-insensitive: the
keyword, industry, company, or person label that surfaced the lead.
engagement_type is comment, like, or another reaction.
search matches the lead's name or headline, case-insensitive,
substring. created_from / created_to are ISO 8601 timestamps or
dates (a date alone means midnight UTC); created_from is inclusive,
created_to is exclusive.
sort is created_at_desc (default), created_at_asc,
lead_score_desc, or icp_score_desc. limit (max 200) and offset
page through the result; the response's has_more says whether
another page follows, and total is the count across every page, not
just this one.
To fetch only what is new since a previous call, sort by
created_at_asc and set created_from to the newest detected_at
already held, then skip any id already seen — one run's leads share
a single detected_at.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | created_at_desc | |
| limit | No | ||
| offset | No | ||
| search | No | ||
| keyword | No | ||
| max_score | No | ||
| min_score | No | ||
| signal_id | No | ||
| created_to | No | ||
| created_from | No | ||
| engagement_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, but the description adds cost ('Free'), a hard tenancy constraint (leads are always the caller's own account; no cross-account fetch), default result size, and pagination semantics (has_more, total spans all pages). These are behavioral facts not present in the structured fields.
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?
Front-loaded with purpose, cost, and tenancy, then organized parameter-by-parameter. It is long, but with 11 undocumented parameters nearly every sentence carries unique information; only the incremental-polling paragraph is arguably extra.
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 the description correctly avoids enumerating return fields while still explaining the two response fields that affect control flow (has_more, total). For an 11-parameter paginated list tool, nothing an agent needs 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description documents essentially every parameter: score range 1-3, keyword exact match case-insensitive against signal_keyword, engagement_type values, search substring semantics, ISO 8601 date handling with inclusive/exclusive boundaries, all four sort values, limit max 200, and offset paging. It fully compensates for the schema gap.
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 — 'Fetch the leads this account's engagement signals have found' — and immediately names the signal types that feed it. It is clearly distinguishable from list_signals, which it references as the source of signal_id.
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?
Explains the no-argument default (50 most recent across all signals), when to scope with signal_id versus omit it, and gives an explicit recipe for incremental polling (sort created_at_asc + created_from from newest detected_at + dedupe by id). This is unusually complete routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the signal monitors on this account: each one's signal_id, its name, its type, the profiles it tracks, and whether it is active or paused.
Free. Call this before creating or changing a signal. A signal is identified by its signal_id, and an account can have several of one type. A name is only a label: names can repeat and can be changed, so never pick a signal by its name alone.
| Name | Required | Description | Default |
|---|---|---|---|
| signal_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld, so the bar is lower, and the description still adds real context: the call is 'Free', names are mutable and non-unique while signal_id is the stable identity, and the result is a full account-wide enumeration. It does not mention ordering, pagination, or size limits for accounts with many signals.
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 paragraphs, front-loaded with the resource and its return fields, followed by cost and identity caveats. No sentence is redundant against the schema or annotations.
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 spelled out, yet the description still summarizes them usefully. Combined with the free-call note and the signal_id-vs-name rule, an agent has what it needs to call and interpret this correctly; only filtering semantics for signal_type are left implicit.
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 0%, so the single signal_type parameter is documented nowhere but its enum literals. The description's phrase 'its type' and 'an account can have several of one type' hints that type matters for identity, but it never says that signal_type filters the listing or what an omitted value does (default null).
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 ('List the signal monitors on this account') and enumerates exactly what comes back: signal_id, name, type, tracked profiles, active/paused status. The closing lines separate it from the mutation siblings (create_signal / update_signal), so an agent can distinguish it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this before creating or changing a signal' gives an explicit precondition that routes the agent away from create_signal/update_signal. It also warns never to identify a signal by name alone, which is actionable selection guidance. It stops short of naming a true alternative (e.g. list_signal_leads for per-signal results) or stating when this list is not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find target accounts matching an ideal customer profile. Filters take human-readable strings, or lists of them which are OR-ed together.
Costs 10 credits per page. Narrow before paginating.
Use this to build an account list, then search_people with
company_name or company_linkedin_urls to find the people inside
those accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| industry | No | ||
| location | No | ||
| technology | No | ||
| company_type | No | ||
| followers_count | No | ||
| company_headcount | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely new, non-structured information: 10 credits per page and the advice to narrow filters before paginating. It does not describe result volume, page caps, or what an empty result means, so it is not fully transparent.
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?
Front-loaded with the purpose, then filter semantics, then cost, then workflow. Every sentence carries weight. Slight redundancy between the purpose line and the closing workflow sentence, but nothing 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 values need not be explained, and annotations carry the read-only/idempotent profile. The remaining gap is filter-value discovery for 7 undescribed parameters — the description should have named suggest_filter_values or list_filter_values as the way to obtain valid strings.
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 0% across 7 parameters, so the description has to compensate. It does add important semantics — filters accept human-readable strings or lists of strings that are OR-ed together — which resolves the array-combination ambiguity the schema cannot. But per-parameter formats (followers_count as a string, headcount ranges, valid industry values) are undocumented, and it fails to point to list_filter_values or suggest_filter_values for discovering valid values.
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: finds accounts/companies matching an ICP. It also distinguishes itself from search_people as the account-level counterpart to the people-level search, so an agent can route between them. It never says 'company database' explicitly, but 'target accounts' is unambiguous alongside the tool name.
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 concrete sequencing: build the account list here, then call search_people with company_name or company_linkedin_urls to find people at those accounts. That is explicit alternative-routing. No when-not conditions are stated (e.g., don't use this for a single known company — use get_company_profile), which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find people matching an ideal customer profile. Every filter takes a plain human-readable string, or a list of them which are OR-ed together. No internal ids are needed.
Costs 10 credits per page, so this is the easiest tool to overspend with. Narrow the filters before paginating, and only request page 2 if page 1 genuinely did not answer the question.
Notable value sets, which list_filter_values will confirm:
company_headcount: 1-10, 11-50, 51-200, 201-500, 501-1,000,
1,001-5,000, 5,001-10,000, 10,001+
company_type: Public, Private, Non Profit, Educational, Government
years_in_position: Less than 1 year, 1 to 2 years, 3 to 5 years,
6 to 10 years, More than 10 years
followers_count: 1-50, 51-100, 101-1000, 1001-5000, 5001+
recently_changed_jobs=True narrows to people who recently started a
new position — Sales Navigator's "Changed jobs" spotlight. There is no
filter for people who have not changed jobs, so False simply leaves
the search unfiltered on this. posted_on_linkedin=True works the same
way for people who recently posted on LinkedIn — the "Posted on
LinkedIn" spotlight.
keywords is free text matched across the whole profile and narrows
the structured filters rather than replacing them. Max 500 characters.
Target specific companies with company_name, or more precisely with
company_linkedin_urls (company page URLs, resolved for you) or
company_ids (numeric LinkedIn ids, which must be integers).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| school | No | ||
| function | No | ||
| industry | No | ||
| keywords | No | ||
| location | No | ||
| job_title | No | ||
| seniority | No | ||
| technology | No | ||
| company_ids | No | ||
| company_name | No | ||
| company_type | No | ||
| followers_count | No | ||
| profile_language | No | ||
| company_headcount | No | ||
| years_in_position | No | ||
| posted_on_linkedin | No | ||
| company_linkedin_urls | No | ||
| recently_changed_jobs | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations, it discloses cost (10 credits per page), the single biggest behavioral risk, and explains the asymmetric boolean semantics of recently_changed_jobs and posted_on_linkedin, where False leaves the search unfiltered rather than excluding matches. It also documents list OR-ing, the 500-character keywords cap, and that company_linkedin_urls are resolved for the caller.
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 cost warning and the OR-semantics rule are front-loaded and the bulleted value sets are scannable. The only redundancy is mild editorializing ("the easiest tool to overspend with") in an otherwise dense, purposeful block.
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 19-parameter, zero-schema-documentation search tool, the description covers the highest-risk behaviors: pricing, pagination discipline, list semantics, boolean spotlight quirks, and the main filter value sets; an output schema exists, so return shape need not be described. It stops short of covering the remaining straightforward filters, which is the one gap keeping it off a 5.
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 0% across 19 parameters, so the description carries the full burden; it does add real meaning for keywords, company_name, company_linkedin_urls, company_ids, and both booleans, and enumerates valid value sets for four range/enum filters. However, parameters like school, function, industry, location, job_title, seniority, technology, profile_language, and page are left entirely unexplained, so compensation is partial.
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 opening sentence gives a specific verb and resource ("Find people") plus the intended semantic goal ("matching an ideal customer profile"), which immediately distinguishes this filtered-search tool from single-record siblings like get_person_profile. The subsequent filter paragraphs make the scope concrete enough that an agent knows what kind of query this tool answers.
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 states explicit when-to-use constraints: narrow filters before paginating, only request page 2 if page 1 genuinely failed to answer the question. It also routes the agent to the sibling list_filter_values to confirm valid value sets, so alternatives are named rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up matching values for one ICP search filter, for cases where the exact spelling matters — a company, job title, location, school, technology or function.
Costs 1 credit per call, and is charged even when the answer comes from cache. Use it to resolve one specific name you are unsure about. Do not call it speculatively, and do not call it for filters whose values are fixed — list_filter_values covers those for free.
The value field of each result is what to pass to search_people or
search_companies.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| suggest_type | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, openWorld), but the description adds pricing behavior that annotations never carry: 1 credit per call, charged even on a cache hit, which materially changes whether an agent should call it speculatively. It also closes the loop on consumption by telling the caller that the returned `value` field is what feeds search_people/search_companies.
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?
Front-loaded with purpose, then cost, then usage constraints, then the downstream hint — good ordering with no filler sentences. Only minor slack: the category list is partially redundant with the enum, and the awkward line-wrapping makes it read as more fragmentary than it is.
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 read-only, idempotent lookup with an output schema and only two params, this covers purpose, cost, exclusions, alternative, and how to consume the result — more than most definitions. The gap is the semantics of `q`, which the description never characterizes, leaving an agent to guess how to phrase the query.
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 0%, so the description must compensate — it partially does by spelling out the six filter categories that map to the suggest_type enum. However, it says nothing about the `q` parameter: whether it is a prefix, substring, or fuzzy match, case sensitivity, or minimum length. The most important input remains undocumented.
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 ("look up matching values for one ICP search filter") and enumerates exactly which filter kinds it covers (company, job title, location, school, technology, function). That enumeration matches the suggest_type enum, so an agent can tell precisely what domain it operates in and how it differs from the bulk sibling list_filter_values.
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 the positive trigger ("resolve one specific name you are unsure about"), two explicit exclusions ("do not call it speculatively", "do not call it for filters whose values are fixed"), and names the alternative (list_filter_values, for free). This is textbook when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change an existing signal monitor. Free.
action decides what changes, and what else you must pass:
pause / resume — stop or restart monitoring, nothing else needed
add_profiles / remove_profiles — needs profile_urls. Removing
the last profile pauses the monitor automatically.
update_webhook — needs webhook_url, optionally webhook_secret
update_emails — needs additional_emails, which replaces the
current list. Pass an empty list to clear it. The account email is
always kept.
update_activity_types — person_activity only; needs
activity_types (reactions, comments, or both)
rename — needs name, the signal's new label
Prefer pause over delete_signal when the user may want it back.
signal_id says which signal to change. The engagement types always
need it. For job_change, new_post and person_activity it can be
left out only when the account has a single signal of that type; with
several it is required. Get it from list_signals, never by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| action | Yes | ||
| signal_id | No | ||
| signal_type | Yes | ||
| webhook_url | No | ||
| profile_urls | No | ||
| activity_types | No | ||
| webhook_secret | No | ||
| additional_emails | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive=true, idempotent=false, so the safety profile is covered; the description adds real behavioral context beyond that — removing the last profile auto-pauses the monitor, update_emails replaces rather than appends, an empty list clears the list, and the account email is always retained. It stops short of stating permission/auth requirements or irreversibility of remove_profiles.
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?
Front-loaded summary line followed by an action-indexed bullet list; the structure mirrors how the agent must reason (pick action, then supply parameters). Length is justified by eight distinct actions across nine parameters — no sentence is 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?
For a nine-parameter, eight-action mutation tool, the description covers action selection, parameter requirements, prerequisites, side effects, and a conservative alternative to deletion. Return values are handled by the existing output schema and safety by annotations, so nothing material 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?
With 0% schema description coverage, the description carries the full burden and does so: every optional parameter (profile_urls, webhook_url, webhook_secret, additional_emails, activity_types, name, signal_id) is tied to the action that consumes it, including value semantics for activity_types and signal_id's conditional requirement.
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?
Opens with a specific verb and resource ("Change an existing signal monitor"), then enumerates all eight actions so the agent knows the full surface of the mutation. It is clearly distinct from create_signal and delete_signal, and even steers away from delete_signal explicitly.
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 per-action conditions (which extra parameter each action requires), a decision rule ("Prefer pause over delete_signal when the user may want it back"), and a strict prerequisite chain for signal_id (obtain from list_signals, never by name; optional only when a single signal of that type exists). This is close to exhaustive routing guidance.
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_creditscreate_signaldelete_signalget_company_funding_roundsget_company_postsget_company_profileget_job_detailsget_person_activityget_person_profileget_postget_post_engagementlist_filter_valueslist_signal_leadslist_signalssearch_companiessearch_peoplesuggest_filter_valuesupdate_signalLive LinkedIn data for AI agents: profiles, companies, jobs, posts, email finding. No account risk.
LinkedIn data for AI agents: profiles, companies, jobs, posts, search. Sales research, recruiting.
LinkedIn jobs, companies and people for AI agents, plus messages and invites via your own account.
LinkedIn data for AI agents: search, profiles, companies, posts. Free key, self-minted, no signup.
Add one secure layer between your agents and this server.