Fresh Linkedin Profile Data MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0
Disambiguation2/5
There are multiple overlapping company and lead search tools (search_companies, get_companies, search_companies_instantly, search_companies_by_sn_url, search_leads, search_leads_v2, lead_search_at_scale), some with identical 'Get search results' descriptions. While many retrieval tools are distinct, the boundary between async search, status, and result-fetching endpoints is easy for an agent to confuse.
Naming Consistency2/5
The set mixes get_* and search_* patterns with exceptions like count, enrich_lead, find_custom_headcount, google_profiles, and lead_search_at_scale. It also contains inconsistent v2 suffixes, generic names, and the typo get_companys_posts, making the naming pattern unreliable.
Tool Count2/5
39 tools is far beyond the typical well-scoped MCP surface, even for a broad LinkedIn data product. The count feels bloated largely because search functionality is split across many overlapping variants rather than consolidated.
Completeness4/5
For a read-only LinkedIn data enrichment server, the surface covers companies, profiles, posts, jobs, leads, decision makers, and school/company searches quite thoroughly. Minor gaps exist, such as no explicit employee-list or full profile-experience endpoint, but most lead-generation workflows have no dead ends.
Average 2.4/5 across 39 of 39 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It discloses nothing about side effects, data returned, access requirements, or limitations. The pricing note does not contribute to behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short but not appropriately sized because it omits essential functional information. It is not front-loaded with useful content; the pricing note is irrelevant to tool usage. No sentence earns its place in a functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is grossly incomplete. It fails to explain what the tool returns, how to interpret results, or any prerequisites. An agent has no idea what to expect or how to act on the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the sole parameter linkedin_url is described with an example). Per rubric, high coverage gives a baseline of 3. The description adds nothing beyond the schema, but the schema is self-explanatory for a simple URL input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only '**1 credit per call.**' which is a pricing note and does not state what the tool does. The tool name hints at retrieving a LinkedIn user's open-to-work status, but the description itself is tautological (repeats nothing) and provides no verb or resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool, what alternatives exist, or any exclusions. The description is entirely silent on usage context, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only hints at a scraping/pagination behavior ('scrape all results from each search') but says nothing about side effects, rate limits, required setup, return value, or failure modes. The fragment is not a meaningful behavioral description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but it is truncated mid-sentence ('change the parameter "') and does not convey a complete idea. This is under-specification, not effective conciseness; brevity without completeness has no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a job-search tool amid 40+ sibling tools, an effective description must at least state what the tool does, how it relates to search_jobs_v2, and what inputs or outputs are involved. This description provides none of that, and there is no output schema or annotation to fill the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, yet the description instructs the agent to 'change the parameter' without naming it or explaining its values. This directly contradicts the empty schema and makes parameter understanding actively misleading rather than helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a sentence fragment: 'To scrape all results from each search, change the parameter "' — it hints at scraping but never states what the tool does, what resource it operates on, or what output to expect. It is truncated and leaves the agent to infer the actual purpose from the name/title alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives like search_jobs_v2, get_search_results, or check_search_status, nor any condition that would select this tool over them. An agent gets no decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description discloses no behavior: no output shape, no side effects, no assumptions, no access prerequisites. The cost note ('5 credits per call') is the only extra fact and it is not a behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but the one sentence it contains ('5 credits per call') does not explain the tool's purpose. This is under-specification rather than useful conciseness, yet it is at least not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description needs to carry the contextual load, and it fails to do so. The agent cannot know what 'insights' are returned, what the company_id refers to beyond an identifier, or what calling this tool entails beyond credit cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 despite the description adding nothing about company_id. The schema itself only provides an example value, so there is some semantic weakness, but the description is not responsible for further compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says only '5 credits per call' and never states what the tool does. The title 'Get Company Insights' is the only hint, but the tool definition itself offers no verb-resource statement. This is effectively missing, and no distinction from siblings is drawn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus sibling tools like get_company_by_id or get_company_by_url, and no context for selecting it. The absence of any description leaves the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states '2 credits per call.' It does not mention pagination behavior, required tokens, data returned, or any operational side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short but not usefully concise—it is severely under-specified. The only sentence ('2 credits per call.') does not help an agent understand or invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, no annotations, and no output schema, yet the description provides no functional context. An agent cannot determine what data this returns, how to chain pagination, or how it differs from sibling post-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 description. The tool description adds no parameter-level meaning, but the schema largely compensates, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is '2 credits per call.' and contains no verb or resource indicating what the tool does. The name 'get_companys_posts' implies fetching a company's posts, but the description itself provides no purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as search_posts, get_profiles_posts, or get_post_details. The description only mentions credit cost and provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions only credit cost and says nothing about side effects, pagination behavior, filtering semantics, response characteristics, or authorization needs. This is almost entirely non-disclosure of behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is extremely short, but brevity here is under-specification rather than conciseness. A single cost statement does not constitute a useful tool description and leaves nearly all functional information absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, yet the description provides no functional context whatsoever. It fails to explain what the tool returns, how pagination works, what 'type' means, or why this tool differs from many related post- and reaction-related siblings. The definition is completely inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter providing an example or default value. The description adds no parameter-level meaning, but the schema is sufficient to understand the parameters' roles. Baseline of 3 is appropriate since the schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only '1 credit per call.' It does not state what the tool does, what resource it acts on, or what operation it performs. The name and title imply 'get reactions for posts,' but the description itself is functionally empty and misleading as a purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_posts_comments, get_post_details, or get_profiles_posts. No use cases, prerequisites, or exclusions are provided. An agent has no basis for selecting this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but '1 credit per call' only states a pricing detail. It does not mention output behavior, side effects, authentication, or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short, but it is under-specified rather than concise. The only sentence conveys billing information and provides no functional value to an agent deciding whether or how to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a single parameter, but with no output schema and no annotations, the description should explain what the tool returns and how it behaves. Instead, it gives only a credit cost, leaving the agent to infer semantics from the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the domain parameter is documented with an example value. The description itself adds no parameter meaning, but the schema already carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only '1 credit per call,' which says nothing about what the tool does. The name/title imply it retrieves a company by domain, but the description itself is missing a purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus siblings like get_company_by_url or get_company_by_id. The description provides no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the credit cost and reveals nothing about what the call does, what 'open profile status' means, what response shape to expect, or any side effects or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short but this is under-specification, not effective conciseness. The single sentence about credits is not front-loaded tool semantics; it is the only sentence and contains no useful operational guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotation coverage, so the description must explain return values and behavior. It does neither. For a status-checking tool with a single input and no output schema, an agent lacks essential information about what statuses exist or what the response will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 linkedin_url property only gives an example value rather than a real semantic explanation, but the tool name and example still convey the expected input format. The description adds nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only '**1 credit per call.**' It never states what the tool does, identifies the resource, or provides a verb. The title and name imply a purpose, but the description itself is semantically empty and does not differentiate from the very similar sibling get_open_to_work_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as get_open_to_work_status or enrich_lead. An agent cannot infer prerequisites, typical use cases, or exclusions from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It says nothing about pagination, sorting, auth requirements, output structure, or side effects; the only behavioral trait mentioned is the credit cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is extremely short, but it is under-specified rather than concise. The single sentence covers cost while omitting the actual purpose, so it does not effectively earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is severely incomplete. An agent lacks purpose, usage context, and behavioral information needed to invoke it correctly among many similar post-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with example values and defaults for all parameters, so the schema already carries parameter semantics. The description adds no parameter meaning, but the baseline of 3 applies because the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states '1 credit per call' and never identifies the verb or resource. The name and title imply retrieving comments on posts, but the description itself provides no purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus siblings like get_posts_reactions or get_post_details. Cost information does not help an agent select the correct tool, and no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry behavioral disclosure. It does disclose the per-call credit cost, which is a useful non-functional trait, but it omits what the tool returns, errors, or side effects. The main behavior is entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is extremely short, but this is under-specification rather than concise description. A single cost note cannot substitute for a functional explanation; the description is not front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, an agent needs to know what 'get_profile_pdf_cv' does, what input format is expected, and what the output will be. The description provides none of that, only credit cost, making it inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters (linkedin_url), and the parameter description includes an example URL. The tool description adds nothing about the parameter's meaning beyond that example, but with high schema coverage the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only '**1 credit per call.**' — it states a cost but never describes what the tool does. The title hints at fetching a profile PDF CV, but the description itself provides no functional purpose, so an agent cannot infer the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus any of the 40+ siblings. There is no mention of contexts, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It mentions only the credit cost and reveals nothing about side effects, return behavior, rate limits, or data scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than concise in a helpful way. A single cost line does not earn its place because it leaves the tool's purpose entirely unexplained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no purpose statement, the description is critically incomplete. An agent has no basis for selecting or invoking 'google_profiles' correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with 0 parameters, so there are no parameters to document. Baseline for zero-param tools is 4; the description adds nothing semantically but also has no parameter burden to meet.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states '**2** credits per call' and never says what the tool does. There is no verb, no resource, and no indication of what 'google_profiles' returns or how it relates to the other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what problem it solves, or when to prefer a sibling like search_leads or get_profiles_posts. The description provides zero context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it only reveals credit cost. It does not disclose what the call returns, whether it mutates anything, what side effects occur, or what 'extra option' means. The pricing information is useful but far from sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is very concise and the pricing cap is clearly stated. However, brevity comes at the expense of essential functional information; the sentence structure itself is efficient, but the content is incomplete for a tool with 12 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema, no annotations, and no functional description, this definition is severely inadequate. An agent has no idea what the tool enriches, what each option does, or what response to expect, making correct invocation largely guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is formally 100%, the descriptions are only 'Example value:' placeholders, with empty examples for 11 optional include_* parameters. The description adds no meaning about what these parameters control or what values they accept, leaving the agent without enough information to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only covers credit pricing ('1 credit per call...') and never states what the tool does, what data is enriched, or how the LinkedIn URL is used. This is effectively a missing purpose statement; the agent must infer function from the tool name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool over its many siblings, such as get_extra_profile_data or get_open_profile_status. There is no mention of prerequisites, alternatives, or conditions, so an agent cannot decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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, and it discloses almost nothing beyond the vague fact that it returns search results. There is no mention of pagination, request_id handling, search lifecycle, or possible errors, and the truncated sentence gives misleading or unparseable behavioral guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but structurally broken: "Please make sure the search is \"" is an incomplete, malformed sentence that provides no value. There is no front-loaded clarity, and the text appears truncated, making it unusable as a concise definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and many closely related siblings, this description is drastically incomplete. It fails to explain how request_id relates to a company search, whether results are paginated, how to interpret the response, or how this tool differs from the many sibling search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 even though the description adds no real parameter insight. The description's incomplete reference to "the search" does not clarify request_id or page, but the schema at least documents both parameters with example values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says only "Get search results," which is vague and fails to identify companies as the resource, especially with the sibling get_search_results present. The truncated sentence adds confusion rather than clarity, and the description does not distinguish this tool from get_company_by_id, get_company_by_url, or search_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided: there is no indication of when to use get_companies versus get_search_results, search_companies, or check_company_search_status. The partial instruction "Please make sure the search is \"" is incomplete and offers no actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral detail disclosed is the credit cost. With no annotations present, the description carries full responsibility for describing side effects, read-only behavior, rate limits, or return behavior, but it provides none of that context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short but under-specified rather than usefully concise. The cost note is a legitimate single piece of information, but a tool description should also convey purpose and behavior; this one does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description needed to explain what is returned and under what circumstances this tool is appropriate. Instead, it provides only a cost notice, leaving the agent without enough context to safely and correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single company_id parameter and includes an example value, so the schema does the necessary work. The description adds no semantic value about the parameter beyond what is already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says only '1 credit per call.' It does not state what the tool does, what resource it acts on, or what operation it performs. The intended purpose must be guessed from the tool name, not from the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_company_by_url, get_company_by_domain, or search_companies. There are no conditions, prerequisites, or exclusions to help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, but it only discloses credit consumption. It does not state whether the operation is read-only, what side effects occur, or any auth, rate-limit, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but under-specification is not conciseness. A single cost sentence leaves no room for purpose or usage context, so it is not appropriately sized for the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no behavioral description, so an agent cannot know what is returned, how the URL format is constrained beyond the example, or how this tool differs from many sibling company-lookup tools. The one-line cost note is far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the required linkedin_url parameter already includes an example in the schema. The description adds no extra meaning beyond the structured input, matching the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is only '1 credit per call,' which is a cost note and does not state a verb or resource. The tool's intended behavior must be inferred entirely from the name, so the description itself provides no purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus siblings such as get_company_by_domain or get_company_by_id. The description neither gives selection criteria nor excludes alternatives, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 disclosing behavior. It reveals nothing about side effects, read-only status, rate limits, authentication, output format, or what happens when a search URL is supplied. The phrase 'Provide search url' is an instruction, not a behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. It contains only one terse sentence and lacks structure, context, or any ordering of important information that would help an agent use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema and no parameters in the schema, the description is not complete enough. It fails to explain the URL format, expected input mechanism, return value, or relationship to the many sibling search tools, so an agent cannot confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the baseline is higher, but the description introduces an input concept ('search url') that is entirely absent from the input schema. An agent cannot determine how to pass the search URL or what format it should take, which creates confusion rather than adding useful parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a directive ('Provide search url instead of filters') rather than a statement of what the tool does. It does not say whether the tool searches leads, returns results, or performs some other action; the tool's purpose is only inferable from the name 'search_leads_v2.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus sibling tools. The phrase 'instead of filters' hints at a contrast with filter-based search tools like search_leads, but it does not specify conditions, exclusions, or alternatives clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 mentions credit cost and omits whether the operation is read-only, what it searches over, whether it returns posts or metadata, or any side effects. This is far below what an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but brevity is not enough; it is under-specified. The single sentence conveys cost, not purpose or behavior, so it does not earn its place as a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though there are no parameters, the tool is one of nearly forty siblings, and the description provides no functional or scoping information. An agent cannot reliably decide whether to call search_posts versus post-related siblings such as get_post_details, get_posts_reactions, or get_companys_posts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to document. The schema already fully captures input requirements, and the description does not need to compensate for missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '2 credits per call' says nothing about what the tool does. The only hint of purpose is in the title, which is not part of the description. It also does not distinguish search_posts from many sibling tools like get_companys_posts, get_profiles_posts, or get_post_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of the many alternatives. The cost note is mildly useful operationally, but it does not explain context, preconditions, or which sibling to prefer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral context, but it only mentions cost. No information is given about data returned, pagination behavior beyond schema hints, rate limits, or any side effects. The cost note is operationally relevant but not behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than conciseness. It contains only a cost note and fails to carry any functional information that would help an agent select or use the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description provides almost no context. While the schema fully documents parameters, the missing purpose, return structure, and usage context make the tool under-specified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented. The description adds nothing beyond the schema, making a baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides no functional statement, only '2 credits per call.' The tool's purpose must be inferred from its name/title, which is ambiguous and does not distinguish it from siblings like get_posts_reactions or get_companys_posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not specify contexts, exclusions, or conditions that would route an agent to this particular endpoint instead of related post-scraping tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 fails to do so: there is no mention of pagination, result limits, asynchronous search behavior, rate limits, or whether the search persists for later retrieval. The truncated phrase about what it returns provides no actual behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not effectively structured: the first sentence duplicates obvious meaning, and the second sentence is cut off mid-phrase. This is under-specification rather than purposeful conciseness, and the incomplete sentence actively harms usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool, an agent needs to know what criteria are accepted, what results look like, and whether search is synchronous or asynchronous. The description provides none of this, and the output schema is absent. Even with zero parameters, the truncated return statement leaves the tool functionally opaque.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to document beyond the schema itself. Per the baseline for zero-parameter tools, the schema already covers everything; the mention of 'your criteria' adds no specific parameter semantics but also does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: 'make a search using your criteria' restates the tool name without specifying what is being searched or what the endpoint actually does. The sentence trails off ('This endpoint will return a "'), so the intended resource and result type are never clearly stated. It also does nothing to distinguish this tool from the many sibling search tools such as search_leads, search_posts, or search_companies_instantly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage signal is the phrase 'Step 1', which vaguely suggests this is the first call in a workflow, but no context explains what that workflow is or when this tool should be selected over alternatives. There is no guidance on prerequisites, follow-up steps, or when to prefer a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only instructs 'Provide URL instead of filters.' It does not disclose what the tool does with the URL, whether it returns a list or single company, whether it is read-only, or any other behavior. This is close to no behavioral disclosure at all.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it is under-specified rather than efficiently complete. The single phrase 'Provide URL instead of filters' attempts a concise contrast, yet it omits context needed for correct invocation, so the brevity is not fully appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and no details about how to provide the URL or what the search returns. An agent cannot reliably determine how to invoke this tool, what input to supply, or what result to expect, making the description inadequate even for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says to provide a URL, but the input schema has zero properties, so there is no URL parameter an agent can populate. This creates a mismatch between the instruction and the structured contract. While 0-parameter tools normally need little parameter documentation, here the description adds misleading semantics instead of useful meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description imply that this tool searches for companies using a Sales Navigator URL rather than search filters, but the description never states an explicit verb and resource ('Searches for companies using a company SN URL'). It hints at the purpose through 'Provide URL instead of filters' but does not clearly differentiate from the sibling get_company_by_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'instead of filters' gives some contextual clue that this tool is for URL-based input rather than filter-based search, which weakly distinguishes it from search_companies. However, it provides no explicit when-to-use guidance, no exclusions, and does not mention relevant alternatives such as get_company_by_url or get_company_by_domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It mentions 'scrape' implying some data-fetching behavior, but does not state whether it is read-only, what data is returned, if it is expensive, or whether authentication is required. The phrase 'advanced filters' is misleading because no filter parameters are exposed in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is concise, but it front-loads a claim ('advanced filters') that is unsupported. Conciseness is not a virtue when it omits essential information. It earns a 3 because it is brief but not effectively structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no parameters, and no output schema, the description is the only source. It fails to explain what 'lead details' are, how filters work (or that there are none), what the return format is, or any operational constraints. Completely inadequate for a tool with this many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines zero parameters, yet the description claims 'advanced filters'. This is a direct contradiction: the agent cannot supply any filters, so the description adds misleading meaning rather than clarifying the schema. Baseline 4 for zero parameters is overridden because the description actively misrepresents the tool's capabilities.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('Find and scrape lead details'), but 'advanced filters' is vague and there is no indication of what distinguishes this from the many sibling search tools like search_leads_v2, lead_search_at_scale, or search_decision_makers. The purpose is partially clear but lacks specificity around scope and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the numerous siblings. There is no mention of context, prerequisites, or alternatives. The description does not help an agent decide between this and search_leads_v2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'Get search results,' implying a read operation, but it does not explain pagination behavior, whether this depends on a prior async search, what happens with stale or missing request IDs, or what response to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is good, but it is also malformed and incomplete, ending with an unfinished quoted phrase. Brevity is not valuable when the content fails to communicate a complete instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no annotations and no output schema, so a complete description is essential. The description does not explain the search lifecycle, the meaning of request_id, pagination semantics, or any error conditions. It is far too incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema properties have descriptions, but they are only example values ('Example value: 1', 'Example value: dd1b...'), not semantic explanations. The tool description adds nothing about how request_id or page should be used, so the agent is left to guess their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get search results.' This is reasonably specific, but it does not differentiate get_search_results from the many sibling search-related tools such as check_search_status or search_leads, so it falls short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No practical guidance is given about when to use this tool versus alternatives. The sentence 'Please make sure the search is "' is an incomplete fragment and provides no usable direction about prerequisites, timing, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It transparently discloses the credit cost and result cap, but it fails to explain the absence of parameters, what 'criteria' actually means, or what the response contains. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the core purpose, limit, and cost. It earns its place, but its brevity leaves out crucial details; still, it is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and a large family of closely related search tools, the description is incomplete. It does not explain how to invoke it, what criteria are, what result shape to expect, or how it differs from siblings beyond 'via Google'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline would normally be 4, but the description introduces a 'criteria' concept that maps to no schema field. This contradiction actively confuses rather than adds meaning, so the parameter-related semantics are poor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and source ('Find up to 100 companies ... via Google') and includes a limit, so an agent knows the basic purpose. However, 'matches your criteria' is undefined because the input schema exposes zero parameters, making the scope vague and potentially misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus sibling alternatives like search_companies or search_companies_instantly. The only differentiator is 'via Google', but no usage context, exclusions, or alternative routes are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, and it only reveals credit cost. It does not mention response behavior, result limits, side effects, or error/timeout behavior, which an unannotated tool needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the credit cost is useful operational information and is front-loaded after the payload note. It is concise, though this brevity contributes to incompleteness elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an unannotated, schema-less search tool, the description is incomplete: it does not state what job search parameters or filters are available, what the results look like, or when this variant should be used. Cost alone is not enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so the baseline is 4: there are no parameter meanings to explain. The description's mention of a simpler payload is consistent but adds no parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description never explicitly states what the tool does; it only adds 'Using a simpler payload,' which presumes the purpose is already known from the name. It offers a comparative distinction from a sibling like search_jobs but no specific verb-resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to call search_jobs_v2 versus search_jobs or related search tools. 'Simpler payload' implies a reason to prefer it, but no condition or exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says it gets a status but does not explain possible status values, whether it returns immediately or blocks, or what the response structure looks like. For a status-checking tool, this lack of detail could cause misjudgment about whether to poll.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero fluff. The core action and key input are front-loaded, making it immediately scannable. It efficiently conveys the essential purpose without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and lack of an output schema, the description should provide more background about what 'status' means, possible values, and how it integrates with the workflow. Omitting these details leaves an agent without the information needed to interpret the response or decide if further actions are required. The reference to 'step 1' is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the request_id parameter (100% coverage), so the baseline is 3. The description adds a small bit of contextual meaning by indicating the request_id comes from a prior step, which is helpful but does not compensate further beyond schema. The description does not introduce additional parameter semantics such as format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the status') and the resource ('your search'), with the required input (request_id). It is unambiguous but does not differentiate from the similar sibling 'check_search_status', which likely serves a generic counterpart. Still, the purpose is specific enough for an agent to understand what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a multi-step workflow ('using the request_id given in step 1') but provides no explicit guidance on when to choose this tool over the sibling 'check_search_status' or any other alternative. There are no exclusions or context about the polling flow, leaving the agent to infer the appropriate usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Find out' implies a read-only operation but doesn't disclose what happens for private profiles, what 'posted' includes, how the date is returned, or the behavior when there are no posts. Behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no filler. It loses a point because the pronoun 'he/she' introduces unnecessary ambiguity and 'posted recently' is colloquial rather than precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description should clarify what exactly is returned (e.g., a date, timestamp, formatted string), whether the input is a LinkedIn profile URL, and any caveats around private profiles or missing posts. The current description is too thin to fully support correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not explain the linkedin_url parameter beyond the schema, and the schema's description is only an example value rather than a semantic explanation, but no additional parameter guidance is required by the baseline. The description adds little meaning for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear goal: find the date of a profile's latest post. However, 'he/she' is vague and there is no differentiation from sibling tools like get_profiles_posts or detect_activity_time, so it stops short of a fully distinguishing definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (checking how recently someone posted) but gives no explicit guidance on when to choose this tool over alternatives, no exclusions, and no mention of related sibling tools. With many similar post/profile tools listed, this is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 adds the per-call credit cost but does not disclose response format, pagination, authentication requirements, failure modes, or whether the operation has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the primary purpose and cost. It wastes no words, though the brevity comes at the expense of useful context. For a one-parameter tool, this level of conciseness is mostly appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the definition is under-specified. It leaves the meaning of 'given' implicit, does not distinguish from get_recommendation_received within the description, and gives no sense of what response the agent should expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the linkedin_url parameter is already documented with an example value. The description adds no additional meaning about URL format, validation, or relationship to the profile, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and resource ('profile's recommendations'), and the parenthetical 'given' contrasts with the sibling tool get_recommendation_received. However, it does not explicitly state whether these are recommendations written by or for the profile, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like get_recommendation_received. The tool name and sibling list imply a distinction, but the definition itself offers no selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says the tool finds and scrapes leads, with no mention of rate limits, long-running processes, pagination, or side effects. This is a vague outline rather than a transparent account of behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. It front-loads the core action and resource. It is slightly too sparse for the number of sibling tools, but as far as conciseness itself, it is appropriately lean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool named 'lead_search_at_scale' with many similar siblings and no output schema, the description is too incomplete. It does not explain what 'at scale' means in practice, how results are returned, or what inputs are expected despite having no schema parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter ambiguity to explain. The schema is effectively complete, and the description does not need to compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a verb ('find and scrape') and a resource ('leads'), and the phrase 'at scale' hints at a bulk operation that differentiates it from more targeted tools like search_leads or search_decision_makers. However, it does not explicitly name a sibling or specify what makes this the scalable version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the many sibling search tools. The phrase 'at scale' implies it should be used for bulk lead acquisition, but the description does not state that or mention any alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It states only that the tool searches, without disclosing return format, pagination, rate limits, filtered inputs, or any other behavioral traits that could affect invocation or result interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It is concise but extremely minimal; however, the lack of structure is more a completeness issue than a conciseness problem.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no annotations, no output schema, and an empty input schema, the description is too thin. It does not specify what input identifies the company, what a 'decision maker' means, or what the returned results look like, leaving the agent with insufficient information to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to explain about parameters. The phrase 'of any company' hints at an implicit company input, but since no parameters exist, there is no schema meaning to supplement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Search') and resource ('decision makers') with an apparent scope ('of any company'). It is somewhat distinguishable from siblings like search_leads or search_companies, though it doesn't explicitly differentiate itself from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus search_leads, search_people, or other sibling search tools. No context about prerequisites or input requirements is provided, so an agent is left to guess when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does disclose cost ('2 credits per call'), which is useful, but it does not explain what 'activity' includes, what the returned time format is, whether the profile must be public, or whether the operation is read-only beyond the implied 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the action and resource, and the second provides the cost detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one well-specified parameter, so the input side is adequately covered. However, with no output schema and no annotations, the description should at least hint at the return format or semantics of 'time'. It is minimally viable but missing key details that would help an agent know exactly what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (100%), so the baseline is 3. The input schema provides an example value for linkedin_url, but no prose definition of the parameter. The tool description itself adds no additional meaning to the parameter, leaving the example as the only guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource ('latest profile activity') and the action ('Get the time'), which is a specific and recognizable operation. It doesn't explicitly distinguish itself from the sibling tool get_profile_latest_post_date, which could overlap semantically, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_profile_latest_post_date, get_open_to_work_status, or get_years_of_experience. The cost note '2 credits per call' is not usage guidance. No context is given for choosing or excluding this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden, but it only adds the credit cost and the fact that a count is returned. It does not disclose output format, what happens when no employees match, how company or criteria are specified, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler: the functional statement comes first, and the credit cost is a separate, useful detail. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description is incomplete for an agent: it references a 'specific company' and 'designated criteria' but the schema has no parameters, and no output schema explains the return value. An agent cannot confidently infer how to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the input schema, so the description is not required to document parameters. It still adds context by emphasizing the company/criteria qualification, though it leaves the mechanism for supplying those unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: discovering the count of employees within a specific company who meet designated criteria. It is specific enough to separate it from many sibling company/lead tools, though it does not explicitly differentiate it from the sibling named 'count' or clarify what 'designated criteria' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the many sibling search/count tools, and no exclusions or prerequisites are mentioned. The description only implies the use case through its purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Get' implies a read-only operation, but the description does not state what happens when a profile has no experience data, whether 'total' spans the full career or just the current role, whether a publicly visible URL is required, or any auth/error behavior. For a tool with zero annotation coverage, this leaves the agent guessing about edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero filler: verb, resource, and scope in one breath. For a one-parameter tool this is appropriately sized; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool (1 parameter, high schema coverage, no enums, no nested objects), and the description covers the invocation contract for the happy path: input a profile URL, get back a number of years. But with no annotations and no output schema, the ambiguity of 'total' (career-wide vs. current role) and missing handling of invalid/private profiles are clear gaps. Adequate as a minimum viable definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single linkedin_url parameter already includes an example value. The description's phrase 'of a profile' loosely confirms the URL identifies the target profile but adds no semantic detail beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a precise resource ('total number of years of experience of a profile'), so an agent knows exactly what data point is returned. It is unambiguous against closely related siblings like get_extra_profile_data or get_open_profile_status because it pinpoints a single scalar value. However, it never names or explicitly differentiates a sibling, which keeps it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to prefer this tool over the many profile-data siblings, no exclusions, and no prerequisites (e.g., whether the linkedin_url must come from a prior lead/enrichment step). Usage is only weakly inferable from the name itself, which the calibration treats as 'no guidance' rather than genuine context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does add useful facts—a 100-school cap and a 2-credit cost and the Google-based method—but it does not describe output shape, pagination, read-only behavior, permissions, or any side effects. This is a meaningful gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The primary capability is front-loaded, and the cost/limit detail is separated cleanly. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of both annotations and an output schema, the description is too thin. It fails to explain what 'criteria' means given an empty input schema, how results are returned, or what the agent should expect after invocation. For a tool with zero parameters, the definition is minimally functional but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is effectively complete, so the description has no parameter burden. The phrase 'match your criteria' hints at inputs that the schema does not define, but since no parameters exist, the baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Find up to 100 schools... via Google.' It is unambiguous about the entity type and the search mechanism, and the name also reinforces the school-pages scope. However, it does not explicitly differentiate itself from direct sibling search_linkedin_company_pages_via_google, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over the many available search tools, nor when not to use it. It implies a use case (finding schools via Google) but gives no exclusions, prerequisites, or alternative routing, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden of behavioral disclosure. It only says 'get the status' and does not describe possible status values, whether the call is non-blocking, whether it can be polled, or what a successful response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant phrasing. The key action and the required parameter are both mentioned immediately, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks an output schema, annotations, and any explanation of the status response. The reference to 'step 1' is vague and unexplained, and the description does not connect this tool to a specific search workflow given the many search-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents request_id with an example. The description adds minor context by noting the ID is 'given in step 1', but it does not add format details or clarify what exactly the status response contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('get') and resource ('status of your search') and references the request_id used to retrieve that status. However, it does not distinguish itself from the closely named sibling 'check_company_search_status', leaving some ambiguity about which search workflow it applies to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying the request_id comes from 'step 1', which gives some workflow context. It does not explicitly explain when to use this tool versus alternatives like check_company_search_status, nor does it mention any prerequisites or polling behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, and it does communicate the core read behavior ('Get...') plus the specific data categories returned. It does not disclose potential failure modes (e.g., private profiles), rate limits, authentication, or response shape, which are meaningful gaps for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the action, target, and examples of returned content with no filler. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is adequate for a simple one-parameter getter that asks for a linkedin_url and returns a known list of field types. However, without an output schema or annotations, the description does not clarify expected output structure, empty/error behavior, or whether the profile must be public.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents linkedin_url with 100% coverage and an example value, so the baseline is 3. The description's mention of 'profile's data fields' weakly reinforces that the URL is a profile URL, but adds no syntax or formatting detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says the tool 'Get more profile’s data fields' and enumerates exact field types (languages, top skills, certifications, publications, patents, awards), making the action and resource clear. It does not explicitly distinguish it from siblings like get_years_of_experience or get_open_profile_status, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this over the many profile-related siblings, nor any exclusions or prerequisites. The phrase 'extra profile data' implies a use case, but the agent is left to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only says 'scrape details', which implies data retrieval but does not reveal read-only status, pagination, returned fields, rate limits, or whether the post must be publicly visible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that efficiently communicates the core purpose and the input requirement without unnecessary words. The key constraint, 'based on its URN', is front-loaded and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup, the description is functionally usable, but with no annotations and no output schema, it leaves the return shape, possible failure reasons, and behavior beyond 'scrape' unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with an example value for urn. The description adds little semantic content beyond tying the URN to the post, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrapes details of one post using its URN, identifying both the action and the resource. It is distinct from search-focused siblings like search_posts, though it does not explicitly contrast against them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: an agent would call this when it has a post URN and needs that post's details. However, there are no explicit when-to-use, when-not-to-use, prerequisite, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does add a useful cost note ('1 credit per call'), but it does not mention the return shape, error behavior, or whether the count reflects only currently open roles vs. historical postings. The credit information lifts it above a bare statement, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences convey the core purpose up front and add the cost detail without any filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only count tool with no output schema, the description provides sufficient context for basic selection: what the tool does and what it costs. However, it omits the response format and any edge-case behavior, which would be helpful given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the only parameter description is an example value ('162479'), which conveys no semantic meaning. The tool description implicitly clarifies that company_id identifies the company whose openings are counted, but it does not explicitly define the parameter's format or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: getting the number of job openings a company has posted on LinkedIn. It is clear and easily distinguished from sibling tools, though it does not explicitly contrast itself with alternatives like search_jobs or get_job_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, nor any exclusions or prerequisite conditions. The only usage signal is implied by the purpose statement itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the tool 'scrapes' data and mentions the credit cost, which is useful. However, it does not describe output format, latency, failure behavior, or any other operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core action and scope are front-loaded, and the cost detail is a useful addition without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple job-details scrape with a single required parameter. However, with no output schema or behavioral annotations, it could be more complete by describing what fields are returned or how the optional parameters affect the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions, so the baseline is 3. The description adds little beyond the schema, only mentioning that company basic information is included in the result, not deepening parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('scrape') and a specific resource ('full job details'), and clarifies it includes company basic information. This clearly distinguishes it from sibling tools like search_jobs or get_post_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. There is no mention of prerequisites, such as having a job URL, nor any comparison to similar job-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does add value by stating the credit cost per call, which is a meaningful operational trait, but it does not describe the return format, permissions, or other side effects. For a simple read-style tool, this is adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The credit-cost note is immediately relevant and the entire description can be consumed in under three seconds.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-type tool, the core purpose is clear and the cost is disclosed. However, without annotations or an output schema, an agent is left to infer the response shape and when this should be chosen over get_recommendation_given. The description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter, linkedin_url, including an example URL, so schema coverage is high. The description adds no additional parameter semantics beyond implying that the profile is identified by a LinkedIn URL, which is already captured by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('profile's recommendations (received)'). The word 'received' directly distinguishes this from the sibling tool get_recommendation_given, so an agent can confidently select between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The cost note ('1 credit per call') is useful operationally, but the description does not mention get_recommendation_given or any other condition that would route an agent to a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the cached nature, annual update cadence, instant performance, and a precise credit-cost rule including the edge case for fewer than 10 results. It does not mention rate limits or authorization, but for a read-only search tool the key behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all informative and front-loaded. The first sentence states the core action and data source, the second adds performance, and the third specifies cost. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema, no annotations), the description is mostly sufficient: it covers source, freshness, speed, and cost. The main gap is that it does not state what the response looks like or how the search query is determined without parameters, though these may be implicit in the tool's design.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline for 0 params is 4. The description adds no parameter-level meaning because none is needed; there is nothing to document beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), a clear resource ('companies'), and the distinctive data source ('cached database of 64 million records updated annually'). The 'Instant results' line separates it from slower search siblings, so an agent can tell it apart from search_companies without opening another schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this when you need instant results from cached data. It does not explicitly name alternatives or state when not to use it, but the contrast between 'instant' and the sibling search tools implies a speed-based choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bach-fresh_linkedin_profile_data MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bach-fresh_linkedin_profile_data/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bach-fresh_linkedin_profile_data)

Score Badge

Copy to your README.md:

[![bach-fresh_linkedin_profile_data MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bach-fresh_linkedin_profile_data/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bach-fresh_linkedin_profile_data)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/bach-fresh_linkedin_profile_data'

If you have feedback or need assistance with the MCP directory API, please join our Discord server