Company and people intelligence for AI agents: deep research with cited sources, URL-to-JSON extraction, contact enrichment from an email or phone number, and company profiles from corporate registries and funding data. 15 tools, API key in the Authorization header.
Scored across 15 tools
Most tools target clearly different data sources and actions (Crunchbase, email, LinkedIn, phone, web search, research). A few boundaries are fuzzy: run_linkedin_domain overlaps with run_linkedin_people_search, and run_phone_enrichment vs run_phone_enrichment_us could both apply to US numbers.
The run_* prefix is used consistently across 14 tools, with domain-specific suffixes like run_email_finder and run_linkedin_people_search. The single outlier is get_session_status, which breaks the otherwise uniform pattern and could have been named run_session_status.
15 tools is at the upper edge of well-scoped for a business intelligence/enrichment server, and each area (email, LinkedIn, phone, search, research) has noticeable coverage. A couple of overlapping tools make it feel slightly heavier than necessary, but the count is still reasonable.
The suite covers the core lead-generation and enrichment lifecycle: search, find, validate, enrich, and research. Minor gaps exist such as no Crunchbase search by name, no way to cancel a research session, and the phone enrichment split leaves generic US behavior somewhat unclear.
Returns the current status of an AI Research session (queued/running/complete/failed) and the final result (human-readable summary plus machine-readable JSON) once processing completes.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session identifier returned by run_research. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does add value by disclosing the status vocabulary and the dual-format result (human-readable summary plus machine-readable JSON) delivered once complete. However, it does not disclose what happens while the session is still queued/running — whether partial data is returned, whether the call is non-blocking, or whether a retry/polling pattern is expected. This gap is notable for a status tool whose whole purpose is monitoring in-progress work.
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 purpose first, then the status values, then the result format. There is no wasted wording and the structure flows logically from what the tool returns to what the result contains. It could arguably be split for readability, but it 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?
For a single-parameter status tool with 100% schema coverage, the description is reasonably complete: it covers both the immediate status output and the eventual result payload. The main missing piece is guidance on behavior for incomplete sessions (e.g., polling semantics), which is partly an artifact of the low complexity here. Given the simplicity of the tool, the gaps are minor.
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% — the schema already documents session_id as the identifier returned by run_research. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies. The cross-reference to run_research is in the schema, not the description.
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 ('Returns'), a specific resource ('status of an AI Research session'), and enumerates the exact status values (queued/running/complete/failed). This clearly distinguishes it from the sibling run_* tools, which are all execution/trigger tools, while this is the status-polling companion to run_research. An agent can instantly tell this apart from the execution 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?
Usage context is implied rather than explicit. The schema description of session_id ('returned by run_research') signals the intended workflow of calling this after run_research, and the sibling list is uniformly run_* execution tools, making the polling role obvious by contrast. However, the description itself never explicitly states 'call this to check progress of run_research' or notes any when-not-to-use conditions, so the guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches structured company data (website, location, founding year, employees, industries, funding, description) from a Crunchbase company URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Crunchbase organization URL, e.g. https://www.crunchbase.com/organization/openai |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and no output schema, so the description carries the transparency burden. It does disclose the read-only nature and the specific data fields returned, but it does not mention behavior for invalid URLs, missing fields, rate limits, or error 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?
A single front-loaded sentence with a parenthetical field list. Every part earns its place, and there is no redundant wording.
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 one-parameter lookup tool, the description is largely sufficient: the input is fully documented by the schema, and the description clarifies the expected output fields. It is missing explicit usage guidance and failure behavior, but the low complexity keeps these gaps minor.
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 schema already documents the url parameter with an example. The description merely restates 'Crunchbase company URL' without adding deeper parameter semantics, so it meets the baseline but adds little beyond 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?
The description uses a specific verb ('Fetches') and names a clear resource: structured company data from a Crunchbase company URL. The enumerated fields (website, location, funding, etc.) make the tool's scope concrete and distinguish it from sibling LinkedIn/email/phone 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?
The use case is implied: use this when you have a Crunchbase company URL and want company data. However, the description does not explicitly state when to prefer this tool over siblings like run_linkedin_company_search, nor does it provide exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enriches a known email address with associated profile data (name, phone, company, position, LinkedIn/X profiles) when available.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to enrich. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not clarify whether this is a read-only lookup or a mutating/enriching operation, and it omits any mention of external data sources, auth requirements, costs, or rate limits. The caveat 'when available' adds some transparency but is not sufficient for a no-annotation tool.
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, front-loaded sentence with no filler. It states the verb, target, output fields, and availability caveat efficiently, earning its place entirely.
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 one-parameter tool with no output schema, the description covers the key outcome: profile data including name, phone, company, position, and LinkedIn/X profiles, with a 'when available' caveat. It is largely complete for a simple enrichment lookup, though it could mention return format or failure behavior explicitly.
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 input schema documents the only parameter with 100% coverage, so the baseline is 3. The description's 'known email address' phrasing adds minor context but no format, validation, or syntax details beyond what the schema already provides.
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 action and resource: 'Enriches a known email address with associated profile data'. The phrase 'known email address' helps distinguish this from sibling tools like run_email_finder and run_email_validation, though it does not explicitly name alternatives.
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 description provides clear context: use this tool when you already have an email address and want associated profile data. It does not list exclusions or explicitly name when to prefer a sibling, but the 'known email address' framing is enough to convey the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds a professional email address for a person given their company domain, first name, and last name.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company domain, e.g. openai.com | |
| last_name | Yes | Person's last name. | |
| first_name | Yes | Person's first name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, yet it only states the intended outcome. It does not mention what happens when no email is found, whether results are verified, what the return value looks like, or any external API or rate-limit considerations.
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 a single, scannable sentence with no filler. Every word earns its place, and the core action and inputs are front-loaded.
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 simple three-parameter lookup, the description and schema are mostly sufficient to invoke the tool. However, with no output schema and no annotations, the lack of detail about returned data, failure behavior, or verification status leaves a meaningful 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 100%, so the baseline is 3. The description connects the three parameters to the purpose, but it adds no additional parameter-level meaning beyond what the schema already provides.
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 ('Finds') and a clear resource ('a professional email address'), and gives the exact input condition: company domain, first name, and last name. It does not explicitly reference sibling tools like run_email_enrichment or run_email_validation, so it stops short of the top score.
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 phrase 'given their company domain, first name, and last name' implies when the tool is appropriate, but it provides no explicit guidance about alternatives, prerequisites, or situations where another tool should be used instead. No exclusions or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates an email address and returns deliverability signals (valid/invalid/risky, catch-all detection, provider, confidence).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to validate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the outputs (deliverability signals) and hints at validation, but doesn't state potential side effects (e.g., sending network requests, rate limits, or data privacy considerations). It doesn't disclose whether it performs only syntax checks or actual delivery testing, which could affect trust.
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 a single, focused sentence that front-loads the main action and states the key outputs. It's efficient, though it could add a brief usage hint without becoming verbose.
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 simple single-parameter validation tool with no output schema, the description is adequate: it specifies the input and the nature of the output. However, it lacks detail on the exact return structure (e.g., is the result a boolean, an object, or a string?) and does not clarify whether the validation is synchronous or asynchronous, which an agent might need to know.
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 schema already documents the 'email' parameter well. The description adds no extra semantics beyond what the schema provides, so a baseline score of 3 is appropriate.
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 clear, specific action ('Validates an email address') and a concrete resource ('an email address'), with the key output signals ('valid/invalid/risky, catch-all detection, provider, confidence'). It distinguishes from sibling tools like run_email_finder (finding addresses) and run_email_enrichment (enriching data), but it doesn't explicitly name 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?
The description implies usage (when you need to validate an email and check deliverability), but gives no explicit guidance on when to use this versus similar sibling tools like run_email_enrichment or run_email_finder. For a simple validation tool, the context is reasonably clear, not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Loads a webpage by URL and extracts structured data from it according to natural-language instructions and/or a JSON schema. Synchronous — returns the result immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the page to load and extract data from. | |
| settings | No | Extraction settings. | |
| instructions | Yes | Natural-language description of what to extract. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It does add useful behavioral context by stating the operation is synchronous and returns the result immediately. However, it does not disclose potential network fetch behavior, failure modes, access restrictions, or whether all page types are supported.
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 two short sentences with no filler. It front-loads the primary function and immediately provides the most important behavioral qualifier (synchronous execution).
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?
Core invocation is covered: URL and instructions are clear, and the optional schema is mentioned. However, with no output schema and no annotations, the description could do more to explain the return format, error handling, or limitations such as unsupported pages. It is adequate but not comprehensive.
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 description adds meaning beyond the schema by clarifying that instructions and/or a JSON schema drive the extraction, and that these can be used together. It does not explain the country_code setting, but schema coverage is high and the core instruction/schema combination is well articulated.
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 clearly identifies the action ('loads a webpage by URL and extracts structured data'), the resource (a webpage), and the output type (structured data). It also names the input modes (natural-language instructions and/or JSON schema), making it easy to distinguish from sibling enrichment/search 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?
Usage is implied: use when you have a URL and need structured data extracted from it. However, the description does not explicitly state when to use this tool instead of siblings like run_research or run_search, nor does it provide exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches LinkedIn employees of one or more given companies, using the same people-style filters as run_linkedin_people_search.
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | LinkedIn company URLs or names to search employees of. | |
| locations | No | ||
| startPage | No | ||
| maxResults | No | ||
| industryIds | No | ||
| scraperMode | No | ||
| searchQuery | No | Free-text search query. | |
| pastJobTitle | No | ||
| functionFilter | No | ||
| seniorityLevelFilter | No | ||
| currentJobTitleFilter | No | ||
| companyHeadcountFilter | No | ||
| yearsOfExperienceFilter | No | ||
| yearsAtCurrentCompanyFilter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but it only says 'Searches' and 'uses filters.' It does not disclose any session/auth requirements, pagination behavior, output shape, LinkedIn scraping risks, or side-effect profile.
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 a single front-loaded sentence with no filler; the scoping clause comes first. However, for a 14-parameter tool it is quite sparse, so it is not optimized beyond brevity.
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 no annotations, no output schema, and 14 parameters, a one-sentence description is incomplete. It omits return format, pagination/startPage behavior, scraperMode meaning, session prerequisites, and how company inputs should be formatted.
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?
Only two of 14 parameters have schema descriptions (~14% coverage), so the description must compensate. It adds some meaning by saying the filter parameters mirror run_linkedin_people_search and it describes 'companies' and 'searchQuery,' but leaves most parameters (e.g., startPage, scraperMode, functionFilter) unexplained except by analogy.
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 precise operation: 'Searches LinkedIn employees of one or more given companies.' The reference to 'people-style filters as run_linkedin_people_search' also helps distinguish it from the company-focused sibling tools like run_linkedin_company_search. Required parameter 'companies' reinforces the resource.
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 makes clear the tool is for finding employees of specific companies, and points to run_linkedin_people_search for filter semantics. It does not explicitly state when not to use it or contrast it with other search tools, so it falls short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches LinkedIn companies by a text query with optional filters (size, industry, location).
| Name | Required | Description | Default |
|---|---|---|---|
| maxItems | No | Maximum number of results to return. | |
| locations | No | Location filters. | |
| startPage | No | Page offset to start from. | |
| companySize | No | Company size buckets, e.g. ['51-200']. | |
| industryIds | No | Industry filters. | |
| scraperMode | No | Scraper depth mode, e.g. 'short' or 'full'. | |
| searchQuery | Yes | Free-text company search query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'searches' without noting that this likely scrapes LinkedIn, may require an active session, has pagination (startPage, maxItems), or has rate limits. The scraperMode parameter implies scraping behavior, but the description does not explain it.
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 a single sentence that is front-loaded with the core action ('Searches LinkedIn companies') and an efficient parenthetical listing optional filters. There is no wasted text, and every word contributes to understanding the tool's purpose.
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 7-parameter tool with no output schema and no annotations, this description is too thin. It does not explain pagination behavior, return format, defaults, session requirements, or the difference between scraperMode values. An agent would still need to infer many important details from the schema and sibling 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 100%, so each parameter already has a meaning. The description adds a small summary by mentioning filters size, industry, and location, which map to parameters, but adds no extra semantics for parameters like scraperMode, startPage, or maxItems. This meets the baseline for full schema coverage.
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 clearly states the verb ('Searches'), resource ('LinkedIn companies'), and scope ('by a text query with optional filters'). It is distinguishable from sibling tools like run_linkedin_people_search or run_crunchbase_company, though it does not explicitly name alternatives.
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 guidance is provided on when to use this tool versus siblings such as run_crunchbase_company or run_search. There is no mention of session prerequisites (e.g., get_session_status) or conditions that would make this tool appropriate or inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds a LinkedIn profile matching a company name or domain plus a full name.
| Name | Required | Description | Default |
|---|---|---|---|
| full_name | Yes | Full name of the person to find. | |
| company_or_domain | Yes | Company name or domain, e.g. openai.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool 'Finds' a profile, without mentioning output shape, failure behavior when no match exists, session or authentication needs, or any other runtime characteristics. This leaves significant behavioral uncertainty.
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 a single, efficient sentence with no filler and starts with the key action. It is appropriately sized for the tool's complexity, though it omits helpful routing or behavioral details that would make it more valuable.
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?
The tool has no output schema and no annotations, and it sits among many similarly named LinkedIn tools. The description explains what the tool searches for but not what it returns, when to choose it over alternatives, or how failures are handled, so an agent is not fully equipped to invoke it correctly.
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 baseline is 3. The description adds the notion that the two parameters are combined ('plus a full name'), but otherwise it essentially paraphrases the parameter names and descriptions without adding meaningful format, constraints, or usage nuance.
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 clearly states a specific verb ('Finds'), a specific resource ('LinkedIn profile'), and the exact matching criteria (company/domain plus full name). It does not explicitly differentiate itself from overlapping siblings like run_linkedin_people_search, so it stops short of full sibling differentiation.
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 when-to-use guidance, exclusions, or mention of alternative tools is provided. With siblings such as run_linkedin_people_search, run_linkedin_company_employee, and run_linkedin_company_search, an agent cannot tell when this tool is preferable over those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up a LinkedIn profile by its full profile URL and returns contact details, including an email address when available.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Full LinkedIn profile URL, e.g. https://www.linkedin.com/in/john-doe/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states what the tool does and notes the email availability ('when available'), which is useful. However, it does not disclose any potential limitations such as authentication requirements, rate limits, or behavior when the profile is not found or the email is not present beyond the caveat. This is adequate for a simple read-only lookup but not rich.
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 a single, well-structured sentence that immediately states the action and result. It front-loads the essential information (lookup by URL) and includes the caveat about email availability without any wasted words.
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 simple, single-parameter tool, the description covers the essential return value (contact details, including email) and the input condition. It does not include an output schema, so the description's mention of the return content is important and present. There is no indication of missing critical information, though it could be more explicit about failure modes. The description is largely complete for the tool's simplicity.
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 schema already describes the sole parameter with a clear format and example (100% coverage). The description reinforces that the tool expects a full URL but adds no new semantic information beyond what the schema provides. Since coverage is high, the baseline of 3 is appropriate.
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 'Looks up' and clearly identifies the resource (LinkedIn profile) and the outcome (returns contact details including an email). It distinguishes from sibling tools by specifying the input as a full profile URL, making it obvious when this tool is appropriate versus search-based 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?
The description implies the intended use case: when you have a complete LinkedIn profile URL and need contact details. It does not explicitly exclude other scenarios or name alternatives, but the clear condition ('by its full profile URL') provides enough context for an agent to select it correctly among siblings like run_linkedin_people_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches LinkedIn people using an optional free-text query and a rich set of advanced filters (company, title, seniority, location, experience, industry).
| Name | Required | Description | Default |
|---|---|---|---|
| lastNames | No | ||
| locations | No | ||
| startPage | No | Page offset to start from. | |
| firstNames | No | ||
| maxResults | No | Maximum number of results to return. | |
| industryIds | No | ||
| pastCompany | No | ||
| scraperMode | No | Scraper depth mode, e.g. 'short' or 'full'. | |
| searchQuery | No | Free-text people search query. | |
| pastJobTitle | No | ||
| currentCompany | No | ||
| functionFilter | No | ||
| seniorityLevelFilter | No | ||
| currentJobTitleFilter | No | ||
| companyHeadcountFilter | No | ||
| yearsOfExperienceFilter | No | ||
| yearsAtCurrentCompanyFilter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it 'searches' people, implying a read operation, but gives no detail on pagination, output format, rate limits, or authentication requirements. It also fails to mention that this may be a live scraping operation, despite the scraperMode parameter.
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 a single, efficient sentence that front-loads the primary purpose and names the key filter groups. Every word contributes value, with no redundancy or 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?
Given the tool's complexity (17 parameters, no output schema, no annotations), this description is severely incomplete. It does not describe the return value, the effect of scraperMode, the meaning of startPage/maxResults, or any pagination behavior. An agent would have to rely on the sparse schema descriptions and would likely misuse the tool. The description is far too high-level for such a parameter-heavy tool.
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 only 24%, so the description must compensate. It lists filter categories (company, title, seniority, location, experience, industry) which map to some parameters like currentCompany, currentJobTitleFilter, seniorityLevelFilter, locations, yearsOfExperienceFilter, and industryIds. However, it does not explain the meaning of many array parameters (e.g., firstNames, lastNames, functionFilter) or clarify how to combine them. This is partial compensation, not full.
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 clearly states the tool searches LinkedIn people with an optional free-text query and a set of advanced filters. It names the resource (LinkedIn people) and the action (searches), and the mention of 'people' distinguishes it from sibling tools like run_linkedin_company_search. This is specific and unambiguous.
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 description gives no guidance on when to use this tool versus alternatives. It does not mention run_linkedin_company_search, run_linkedin_company_employee, or other search tools, nor does it state any exclusions or prerequisites. The only implied usage is that it is for people search, which is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enriches a known phone number with associated profile data (name, email, company, LinkedIn/X profiles, carrier) when available.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Phone number in international format, e.g. +1234567890 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that data is returned 'when available,' implying partial results, but does not mention error handling, authentication, rate limits, or whether the operation is read-only. For a simple enrichment tool, this is a moderate 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?
The description is a single, efficient sentence that front-loads the purpose and lists expected output fields. No wasted words, and it reads naturally.
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?
The tool has one parameter, no output schema, and no annotations. The description lists the data fields returned but does not specify the return structure or behavior when the phone is not found (e.g., empty object, error, null). 'When available' hints at partial data but leaves ambiguity. This is a notable gap for an agent to correctly handle results.
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% – the schema fully describes the 'phone' parameter with format and example. The description adds no new parameter semantics beyond stating it's a 'known phone number,' which is already implied. Baseline 3 is appropriate.
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 clear verb-resource pair: 'Enriches a known phone number' with specific data fields (name, email, company, LinkedIn/X profiles, carrier). It distinguishes from siblings like run_email_enrichment (email) and run_phone_enrichment_us (likely US-specific) by focusing on international phone numbers, though it doesn't explicitly name 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?
The description implies usage: when you have a known phone number and want associated profile data. It does not explicitly contrast with alternatives like run_phone_enrichment_us, so exclusions are missing. However, the context is clear enough for an agent to select this tool for phone-based enrichment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates and enriches a US phone number with carrier, line type, activity score, litigator risk, and owner details.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | US phone number, e.g. 12069735100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core behavior (validation and enrichment) and the returned data categories, but it does not clarify side effects, read-only status, failure behavior, or data freshness. The behavior is not contradictory, just under-specified.
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 compact sentence front-loads the action and then lists the enriched attributes. Every word contributes information; there is no filler or 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?
For a one-parameter tool with no output schema, the description does enough by stating the input scope, the validation action, and the key output fields. It falls short only in not explicitly routing non-US phone numbers to the likely sibling run_phone_enrichment and not indicating behavior on invalid numbers.
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 schema already covers the only parameter fully, including format and example, so the description adds no new parameter-level meaning. The description's mention of enrichment fields provides broader output context, but the parameter semantics themselves come 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?
The description uses a specific verb ('Validates and enriches') with a clear resource ('a US phone number') and enumerates the output categories. The US qualifier distinguishes it from the sibling run_phone_enrichment tool without needing to open either 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?
The scope 'US phone number' implies when this tool should be used, but it does not explicitly state when to prefer run_phone_enrichment_us over run_phone_enrichment or any other sibling. There is no when-not-to-use guidance or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts the full NeuralVerge AI research workflow (multi-step search, analysis, and structured reporting) and returns a session_id immediately. Poll get_session_status with that session_id until status is 'complete' or 'failed'.
| Name | Required | Description | Default |
|---|---|---|---|
| settings | No | Research run settings. | |
| instructions | Yes | Main research task, in natural language. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It clearly discloses the async fire-and-poll behavior and the terminal states, which is the most important behavioral trait. It does not mention cost, cancellation, or side effects, but the core async contract is well covered.
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 with no filler. The core action, the immediate return value, and the follow-up polling instruction are all front-loaded. Every sentence 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?
The description is sufficient for an agent to call the tool correctly: it identifies the sole required parameter concept (instructions), explains the immediate session_id return, and routes to get_session_status. It does not describe how the final report is accessed beyond polling, but the described contract is reasonably complete for this async workflow.
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 both parameters and the nested settings. The description adds no parameter-level meaning beyond what the schema provides; the baseline of 3 is appropriate.
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 ('Starts'), a clear resource ('the full NeuralVerge AI research workflow'), and distinguishes it from sibling run_* tools by noting it is multi-step search, analysis, and structured reporting. An agent can tell this apart from run_search or the other targeted run_* 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?
It gives clear operational context: the tool is asynchronous, returns a session_id immediately, and should be followed by polling get_session_status until 'complete' or 'failed'. It does not explicitly state when not to use it or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a synchronous web search and returns a structured list of ranked results (title, url, snippet) immediately, without polling.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query. | |
| settings | No | Search settings. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is synchronous and returns immediately, and it specifies the result fields. This adds value beyond the schema by informing the agent that polling is unnecessary. However, it omits other behavioral details such as rate limits, error behaviors, authentication requirements, or whether the operation has any side effects, which leaves some gaps for a tool with no annotation coverage.
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 a single, tightly worded sentence that front-loads the core purpose ('synchronous web search') and the output structure, then adds the key behavioral modifier ('without polling'). There is no filler, redundancy, or unnecessary detail, and 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?
The description covers the output shape and the synchronous behavior, which is essential given there is no output schema. However, it does not elaborate on the settings object's fields (country, language, max_results), so an agent may still be unsure what values are valid. For a tool with a nested object and no output schema, this is a moderate gap; the description is useful but not fully 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 100%, so the schema already provides descriptions for the top-level parameters (query and settings). The description does not add any further meaning to the parameters, such as explaining valid country/language codes or max_results limits. Per the baseline rule for high schema coverage, a score of 3 is appropriate; the description adds no parameter semantics beyond 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?
The description clearly states a specific verb ('Runs') and resource ('web search'), and specifies the exact output shape ('title, url, snippet'). It also differentiates from siblings by calling out the synchronous nature and immediate return without polling, which distinguishes it from any asynchronous alternative. An agent can tell this is a generic web search tool, unlike the LinkedIn/email/phone 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?
The description implies usage by noting the synchronous, immediate, no-polling behavior, which hints it is for when results are needed right away. However, it does not explicitly state when to use this tool versus alternatives like run_research, nor does it provide exclusions or conditions rerouting the agent. The guidance is implied rather than explicit.
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.
get_session_statusrun_crunchbase_companyrun_email_enrichmentrun_email_finderrun_email_validationrun_extractrun_linkedin_company_employeerun_linkedin_company_searchrun_linkedin_domainrun_linkedin_emailrun_linkedin_people_searchrun_phone_enrichmentrun_phone_enrichment_usrun_researchrun_search
Add one secure layer between your agents and this server.