LinkedIn Sales & Navigator MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between get_profile, get_profile_details, get_profile_experience, and get_profile_skills, which could cause confusion about which to use for comprehensive profile data. However, the descriptions clarify their specific scopes, and other tools like get_company vs. search_companies are well-differentiated.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with clear and predictable naming such as get_company, search_people, and send_message. All tools use snake_case, and verbs like 'get', 'search', and 'send' are applied consistently across related functions.
Tool Count4/5
With 22 tools, the count is slightly high but reasonable for the broad scope of LinkedIn Sales & Navigator, covering profile management, messaging, search, and Sales Navigator features. It feels comprehensive without being overwhelmingly bloated, though it could benefit from some consolidation in the profile-related tools.
Completeness5/5
The tool set provides complete coverage for the domain, including CRUD-like operations for profiles, companies, conversations, and Sales Navigator leads, with no obvious gaps. It supports core workflows like searching, retrieving details, sending messages, and managing connections, ensuring agents can handle typical LinkedIn tasks effectively.
Average 3.2/5 across 22 of 22 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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 states what the tool does but lacks critical behavioral details: it doesn't specify if this is a read-only operation (implied by 'Get' but not explicit), what 'recent' means (timeframe or recency criteria), whether it requires authentication, rate limits, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information.
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 complexity (a data retrieval tool with pagination), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'conversation threads' include (e.g., metadata, participants), how results are structured, or any behavioral constraints like authentication needs. For a tool with these gaps, it should provide more context to be fully helpful.
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 clear documentation for 'start' and 'count' parameters including defaults. The description adds no additional parameter semantics beyond what the schema provides, such as explaining how 'recent' relates to pagination or result ordering. With high schema coverage, the baseline score of 3 is appropriate as 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 clearly states the verb 'Get' and resource 'recent conversation threads from the LinkedIn inbox', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_conversation_messages' (which might get messages within a conversation) or 'get_pending_connections' (which could involve different inbox aspects), so it lacks sibling differentiation for a perfect 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use it (e.g., for inbox overview vs. detailed messages with 'get_conversation_messages') or any exclusions, leaving the agent to infer usage from context alone.
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 full burden for behavioral disclosure. It states it's a 'Get' operation (implying read-only) but doesn't cover critical aspects like authentication requirements, rate limits, error conditions, or what 'pending outgoing' means in context. The description is too minimal for a tool that likely involves sensitive data.
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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and uses clear terminology. This is an example of optimal conciseness for a simple 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 no annotations, no output schema, and 2 parameters, the description is incomplete. It doesn't explain what 'pending outgoing connection requests' entails, the format of returned data, or any behavioral constraints. The agent lacks sufficient context to use this tool effectively beyond basic parameter passing.
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 both parameters ('start' and 'count') well-documented in the schema. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 for adequate coverage without adding value.
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 verb 'Get' and the resource 'pending outgoing connection requests', which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'send_connection_request' or 'get_profile', though the specificity of 'pending outgoing' helps distinguish it from general connection tools.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication state), nor does it contrast with similar tools like 'get_profile' or 'send_connection_request'. The agent must infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation but doesn't disclose behavioral traits like rate limits, authentication needs, error handling, or what happens if the profile lacks contact info. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what the return values look like (e.g., format of contact info), potential errors, or usage constraints. For a tool with rich context needs, this leaves the agent under-informed.
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 the parameter 'public_identifier' well-documented in the schema. The description adds no additional meaning beyond implying it's for LinkedIn profiles, which is already clear from the schema. Baseline 3 is appropriate as 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 clearly states the action ('Get') and resource ('contact information for a LinkedIn profile'), specifying the data types (email, phone, websites). It distinguishes this tool from siblings like 'get_profile' or 'get_profile_details' by focusing on contact info. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 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 provides no guidance on when to use this tool versus alternatives like 'get_profile' or 'get_profile_details', nor does it mention prerequisites (e.g., needing a valid LinkedIn identifier). It merely states what it does without context for selection among similar tools.
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 full burden. It states it's a read operation ('Get'), but lacks behavioral details like authentication requirements, rate limits, data freshness, or error conditions. For a tool accessing external data without annotation coverage, this is a significant gap.
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?
Single sentence, front-loaded with the core action, efficiently lists included data types without redundancy. Every word earns its place, making it easy to scan and understand quickly.
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, no output schema, and multiple sibling tools, the description is incomplete. It doesn't clarify scope (e.g., whether it returns all profile sections or a subset), differentiate from similar tools, or address behavioral aspects like permissions or limitations, leaving gaps for an AI 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%, with the single parameter 'public_identifier' documented as 'The LinkedIn public identifier / vanity URL slug'. The description adds no additional parameter context beyond implying it fetches LinkedIn profiles, which is already inferred from the schema. Baseline 3 is appropriate when 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 clearly states the verb 'Get' and the resource 'detailed profile information', specifying the included data types (experience, education, skills). It distinguishes from generic 'get_profile' by emphasizing detail level, though doesn't explicitly contrast with siblings like 'get_profile_experience' or 'get_profile_skills'.
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 on when to use this tool versus alternatives like 'get_profile' (likely basic info), 'get_profile_experience' (specific section), or 'get_own_profile' (self-access). The description implies comprehensive details but doesn't specify prerequisites 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 provided, the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), but doesn't mention authentication requirements, rate limits, error conditions, or what the output format looks like (e.g., structured experience data). This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero wasted content.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the returned experience data includes (e.g., job titles, dates, companies) or behavioral aspects like authentication needs. For a tool with no structured output documentation, more context is needed.
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 the single parameter 'public_identifier' clearly documented as 'The LinkedIn public identifier / vanity URL slug'. The description adds no additional parameter semantics beyond this, so it meets the baseline of 3 where 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 clearly states the action ('Get') and the specific resource ('work experience listed on a LinkedIn profile'), which distinguishes it from general profile retrieval tools like 'get_profile'. However, it doesn't explicitly differentiate from other experience-related tools (none exist in the sibling list), so it doesn't fully earn 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?
The description provides no guidance on when to use this tool versus alternatives like 'get_profile' (which might include experience) or 'get_profile_details'. There's no mention of prerequisites, context, or exclusions, leaving the agent with minimal usage direction.
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. It states the tool retrieves skills but doesn't mention whether this is a read-only operation, if authentication is required, rate limits, or what the return format looks like. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of skills, structured data), potential errors, or behavioral traits like authentication needs. For a tool with no structured support, this leaves significant gaps.
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, clearly documenting the 'public_identifier' parameter. The description doesn't add any extra meaning beyond what the schema provides, such as examples or format details, so it meets the baseline score of 3 for high schema coverage.
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') and resource ('skills listed on a LinkedIn profile'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_profile' or 'get_profile_details', which might also retrieve profile information, so it doesn't fully distinguish itself from alternatives.
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 guidance on when to use this tool versus alternatives such as 'get_profile' or 'get_profile_details'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage based on the tool name alone.
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. It only mentions the subscription requirement, lacking details on permissions, rate limits, response format, or pagination behavior. This is insufficient for a tool that likely involves data retrieval and potential constraints.
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, efficient sentence that directly states the purpose and prerequisite without unnecessary words. It is front-loaded and appropriately sized for the tool's complexity.
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 no annotations and no output schema, the description is incomplete. It fails to explain what the tool returns (e.g., lead details, pagination info) or other behavioral aspects like error handling. For a data retrieval tool with potential subscription dependencies, more context is needed.
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 clear documentation for 'start' and 'count' parameters. The description adds no additional parameter information, so it meets the baseline score of 3, as the schema adequately covers the semantics.
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') and resource ('saved leads from Sales Navigator'), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'get_lead_lists' or 'sales_search_leads', which might retrieve similar data, so it doesn't reach the highest 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?
The description mentions a prerequisite ('requires Sales Navigator subscription'), which provides some context, but it doesn't specify when to use this tool versus alternatives like 'get_lead_lists' or 'sales_search_leads'. No explicit guidance on when-not-to-use or comparisons is given.
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. While it mentions the search functionality, it doesn't describe important behavioral traits like whether this is a read-only operation, what permissions are required, rate limits, pagination behavior beyond the schema parameters, or what the return format looks like. For a search tool with zero annotation coverage, this leaves significant gaps.
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, efficient sentence that clearly states the tool's purpose and main parameters. It's appropriately sized and front-loaded with essential information, with zero wasted words or unnecessary elaboration.
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 6 parameters and no annotations or output schema, the description is incomplete. It doesn't explain what the tool returns, how results are structured, any limitations or constraints, or how it differs from similar sibling tools. The description provides only basic functionality without the context needed for effective agent use.
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 description lists the search criteria (keywords, industry, region, size) which maps to 4 of the 6 parameters. However, with 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds minimal value beyond what's in the schema, providing only a high-level overview without additional semantic context.
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's purpose as searching for companies on LinkedIn using specific criteria (keywords, industry, region, size). It uses a specific verb ('search') and identifies the resource ('companies on LinkedIn'), but doesn't explicitly distinguish this from sibling tools like 'sales_search_accounts' or 'search_people' which might have overlapping functionality.
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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'sales_search_accounts' or 'search_people' that might serve similar purposes, nor does it specify any prerequisites, exclusions, or contextual constraints for 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 provided, the description carries full burden for behavioral disclosure. It mentions the search capability and filter types but fails to describe important behavioral aspects: whether this is a read-only operation, what the response format looks like, any rate limits, authentication requirements, or whether it's a paginated search. The description is insufficient for a mutation-sensitive agent.
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, efficient sentence that front-loads the core purpose and enumerates filter types in a parenthetical. There's zero waste or redundancy. Every word serves to clarify the tool's function.
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 10 parameters and no annotations or output schema, the description is incomplete. It doesn't explain what the search returns (profiles? contact info?), how results are structured, pagination behavior beyond the schema's 'start' and 'count' parameters, or any limitations on search scope. The agent lacks sufficient context to use this tool effectively.
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 schema already documents all 10 parameters thoroughly. The description adds minimal value by listing filter categories ('keywords, company, industry, location, title, school, network depth') but doesn't provide additional semantic context beyond what's in the schema. This meets the baseline for high schema coverage.
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's purpose: 'Search for people on LinkedIn with various filters'. It specifies the verb ('search'), resource ('people on LinkedIn'), and scope ('with various filters'). However, it doesn't explicitly differentiate from sibling tools like 'get_profile' or 'sales_search_leads', which prevents a perfect 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this search tool is preferred over 'get_profile' (for specific individuals) or 'sales_search_leads' (for sales-focused searches), nor does it provide any context about prerequisites or limitations.
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 states the tool reads messages but doesn't cover critical aspects like authentication requirements, rate limits, error conditions (e.g., invalid conversation ID), response format, or whether it's idempotent. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that front-loads the core purpose ('Get messages from a specific LinkedIn conversation thread'). There is no wasted verbiage, repetition, or unnecessary detail, making it easy for an agent to parse quickly.
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?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks behavioral details (e.g., authentication, errors) and usage guidelines. Without an output schema, the description doesn't hint at return values, leaving the agent uncertain about what to expect from the tool's execution.
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 clear documentation for all three parameters (conversation_id, start, count). The description adds no additional semantic context beyond what the schema provides—it doesn't explain parameter interactions (e.g., how start and count work together for pagination) or constraints (e.g., maximum count values). With high schema coverage, 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 action ('Get messages') and resource ('from a specific LinkedIn conversation thread'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'get_conversations' (which likely lists conversations rather than messages within one) and 'send_message' (which writes rather than reads). However, it doesn't explicitly mention pagination or filtering capabilities, which would make it more specific.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid conversation ID), exclusions (e.g., not for group chats if applicable), or comparisons to similar tools like 'get_conversations'. Without such context, the agent must infer usage from the name and schema alone.
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 mentions InMail requirements but doesn't cover critical aspects like whether this is a read-only or mutating operation, permission requirements, rate limits, response format, or potential side effects (e.g., notifications). For a messaging tool with zero annotation coverage, this leaves significant gaps in understanding its 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 concise and front-loaded with the core purpose in the first sentence. Both sentences earn their place by providing essential details (URN format and InMail subject requirement). However, it could be slightly more structured by separating usage notes from parameter details.
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 complexity of a messaging tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., mutation effects, auth needs), response expectations, and differentiation from sibling tools. While it covers basic purpose and some parameter hints, it doesn't provide enough context for safe and effective use by an AI 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 the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema by specifying the URN format ('urn:li:fsd_profile:MEMBER_ID') and noting subject requirements for InMail, but doesn't provide additional semantic context or usage examples. Baseline 3 is appropriate when the schema does most of the work.
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 ('Send a message') and target ('to a LinkedIn member'), which is specific and unambiguous. However, it doesn't explicitly differentiate this from 'send_connection_request' (a sibling tool), missing an opportunity to clarify when to use messaging versus connection requests.
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 provides some implied usage guidance by mentioning 'For InMail, include a subject,' which suggests context for when the subject parameter is required. However, it lacks explicit when-to-use guidance relative to alternatives like 'send_connection_request' or other communication tools, and doesn't mention prerequisites 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 provided, so the description carries the full burden of behavioral disclosure. It states the tool validates session activity but doesn't explain what 'active and working' entails (e.g., returns status codes, error messages, or session details). It lacks details on permissions, rate limits, or potential side effects, which is a gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any fluff or redundancy. It is front-loaded and efficiently conveys the essential information, making it highly concise and well-structured.
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 purpose (session validation) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the validation entails, what output to expect (e.g., success/failure indicators), or how it integrates with other tools. For a session-related tool, this leaves significant gaps in understanding its role and behavior.
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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids unnecessary details. A baseline of 4 is applied as it handles the lack of parameters correctly without confusion.
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's purpose: 'Validate that the LinkedIn session cookie is still active and working.' It specifies the verb 'validate' and the resource 'LinkedIn session cookie,' making the action explicit. However, it does not distinguish this from sibling tools, which are primarily data retrieval or messaging tools, so it doesn't fully differentiate in context.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a session cookie first), exclusions, or how it relates to sibling tools like authentication or session management tools. This leaves usage context unclear.
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 mentions the subscription requirement, which is useful context. However, it lacks details on pagination behavior (implied by parameters but not explained), error handling, rate limits, or what the output looks like (no output schema). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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, efficient sentence that front-loads the core purpose and includes a key prerequisite. There is no wasted verbiage or redundancy, making it easy to parse quickly. Every word earns its place by contributing essential information.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain the return format (e.g., list of lead objects), pagination details beyond parameter names, or potential errors. For a tool with three parameters and no structured output documentation, more context is needed to fully understand its operation and results.
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 description coverage is 100%, with clear descriptions for all three parameters (list_id, start, count). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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') and target resource ('leads within a specific Sales Navigator lead list'), making the purpose immediately understandable. It distinguishes itself from siblings like 'get_lead_lists' (which retrieves lists) and 'get_saved_leads' (which retrieves saved leads). However, it doesn't specify the exact scope (e.g., all leads vs. filtered) beyond the list context.
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 includes a prerequisite ('requires Sales Navigator subscription'), which provides some usage context. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_saved_leads' or 'sales_search_leads', nor does it mention any exclusions or complementary tools. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the subscription requirement, which is useful context, but lacks details on rate limits, authentication needs, response format, or whether it's a read-only operation. For a tool with no annotations, this is a significant gap in transparency.
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, efficient sentence that front-loads the core purpose and includes a key constraint. There is no wasted text, making it highly concise and well-structured for quick understanding.
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 no annotations and no output schema, the description is incomplete. It covers the basic purpose and a prerequisite but lacks details on behavior, return values, or how it differs from sibling tools. For a tool with 2 parameters and no structured support, this leaves significant gaps in context.
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 both parameters ('start' and 'count') clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 without compensating or adding value.
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') and resource ('lead recommendations from Sales Navigator'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'sales_search_leads' or 'get_saved_leads', which might offer alternative ways to access lead data, so it doesn't reach the highest score.
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 includes a prerequisite ('requires Sales Navigator subscription'), which provides some context for when to use it. However, it doesn't specify when to choose this tool over similar siblings like 'sales_search_leads' or 'get_saved_leads', leaving usage guidelines implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool retrieves 'detailed information', but doesn't specify what details are included, whether it's read-only, requires authentication, has rate limits, or error behaviors. For a tool with zero annotation coverage, this is a significant gap in transparency, though it doesn't contradict any 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?
The description is a single, efficient sentence that front-loads the core purpose ('Get detailed information about a company') and specifies the key parameter. There is no wasted text, and it directly addresses the tool's function without redundancy, making it highly concise and well-structured.
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?
Given the tool's low complexity (1 parameter, no nested objects) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it fails to explain behavioral aspects like what 'detailed information' entails or response format. For a read operation, this leaves gaps that could hinder agent understanding, though the simplicity mitigates severity.
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 the parameter 'universal_name' fully documented in the schema as 'The company's universal name / vanity URL (e.g. 'google')'. The description adds minimal value beyond this, reiterating the parameter type without providing additional context like format constraints or examples beyond what's in the schema. Baseline 3 is appropriate as 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 clearly states the action ('Get detailed information') and resource ('about a company'), specifying it uses a 'universal name (vanity URL slug)' for identification. It distinguishes from siblings like 'search_companies' by focusing on retrieval of a specific company rather than searching. However, it doesn't explicitly contrast with 'get_profile' tools, which target individuals, leaving some sibling differentiation implicit.
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 specifying the parameter ('universal name'), suggesting it's for fetching known companies, but lacks explicit guidance on when to use this versus alternatives like 'search_companies' or 'sales_search_accounts'. No exclusions or prerequisites are mentioned, leaving the agent to infer context from the parameter requirement alone.
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. It mentions a subscription requirement, which is useful context, but lacks details on permissions, rate limits, response format, or error handling. For a read operation tool, this leaves significant gaps in understanding its behavior beyond the basic action.
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, efficient sentence that front-loads the key information (action and resource) and includes a necessary prerequisite without any wasted words. It's appropriately sized for the tool's complexity.
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?
Given the tool has one parameter with full schema coverage and no output schema, the description is minimally adequate. It covers the basic purpose and a key prerequisite, but for a tool with no annotations, it should ideally provide more behavioral context like response details or error scenarios to be fully 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 has 100% description coverage, with the 'lead_id' parameter clearly documented. The description doesn't add any extra meaning or details about the parameter beyond what the schema provides, such as format examples or constraints. Baseline score of 3 is appropriate since 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 clearly states the action ('Get') and resource ('a lead's profile from Sales Navigator'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_profile' or 'get_profile_details', which appear to serve similar purposes, so it misses full sibling distinction.
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 includes a prerequisite ('requires Sales Navigator subscription'), which provides some context for when to use it. However, it doesn't offer explicit guidance on when to choose this tool over alternatives like 'get_profile' or 'get_profile_details', nor does it specify exclusions or detailed usage scenarios beyond the subscription requirement.
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. It mentions the Sales Navigator subscription requirement, which is useful context, but lacks details about rate limits, authentication needs, pagination behavior (beyond what's in the schema), error handling, or what the search results look like. For a search tool with no annotation coverage, this leaves significant gaps.
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, efficient sentence that front-loads the core purpose and includes essential context (Sales Navigator requirement). There's no wasted verbiage or redundancy, making it highly concise and well-structured.
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?
Given the tool's moderate complexity (search with 5 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and subscription requirement but lacks details about behavioral traits, result format, or explicit sibling differentiation. It meets the bare minimum for a search tool but leaves room for improvement.
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 schema already documents all 5 parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema (e.g., it doesn't explain keyword syntax, geography/industry format options, or pagination defaults). Baseline 3 is appropriate 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 clearly states the action ('Search for accounts (companies)') and specifies the resource ('using LinkedIn Sales Navigator'), making the purpose unambiguous. It distinguishes from some siblings like 'search_companies' by mentioning the Sales Navigator requirement, though it doesn't explicitly differentiate from 'sales_search_leads' which is a similar sibling tool.
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 provides some usage context by stating 'requires Sales Navigator subscription', which is helpful for prerequisites. However, it doesn't explicitly guide when to use this tool versus alternatives like 'search_companies' or 'sales_search_leads', leaving the agent to infer based on tool names alone.
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 mentions the requirement for a Sales Navigator subscription, which is useful context about prerequisites. However, it doesn't describe other behavioral traits such as rate limits, authentication needs, whether it's a read-only operation, what the output format looks like, or any potential side effects. For a search tool with zero annotation coverage, this leaves significant gaps.
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, efficient sentence that states the purpose and a key prerequisite. It's appropriately sized and front-loaded with the core functionality, with no wasted words or unnecessary elaboration.
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?
Given the complexity (9 parameters, no annotations, no output schema), the description is minimally adequate. It covers the basic purpose and a prerequisite, but doesn't provide enough context about behavior, output, or usage compared to siblings. For a search tool with many parameters and no structured output documentation, more detail would be helpful to ensure the agent can use it correctly.
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%, meaning all parameters are documented in the input schema. The description doesn't add any additional meaning or context about the parameters beyond what the schema provides. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter info in the description.
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 searches for leads using LinkedIn Sales Navigator, which is a specific verb (search) and resource (leads). It distinguishes from some siblings like 'get_lead_lists' or 'get_saved_leads' by focusing on search rather than retrieval, though it doesn't explicitly differentiate from 'search_people' or 'sales_search_accounts' which are similar search operations.
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 mentions that it requires a Sales Navigator subscription, which provides some context for when to use (i.e., when that subscription is active). However, it doesn't provide explicit guidance on when to choose this tool versus alternatives like 'search_people' or 'sales_search_accounts', nor does it specify exclusions or prerequisites beyond the subscription.
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. It mentions the tool fetches a profile but does not disclose behavioral traits such as whether it requires authentication, rate limits, what data is returned, error handling for invalid identifiers, or if it's a read-only operation. The description is minimal and lacks essential operational context.
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, efficient sentence with zero waste. It front-loads the core purpose and includes a helpful example without unnecessary details. Every word earns its place, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It does not cover what the tool returns (e.g., profile fields, format), authentication requirements, error cases, or limitations. For a tool that likely interacts with an external API and returns structured data, more context is needed to guide effective use.
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 description coverage is 100%, with the parameter 'public_identifier' fully documented in the schema. The description adds minimal value by reiterating the parameter as 'public identifier (vanity URL slug)' and providing an example, but does not explain semantics beyond what the schema already states. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a LinkedIn profile'), specifies the input method ('by public identifier'), and provides a concrete example ('vanity URL slug, e.g. 'john-doe-123''). It distinguishes itself from siblings like get_own_profile (which fetches the user's own profile) and get_profile_details/experience/skills (which retrieve specific profile sections).
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 specifying the input type ('public identifier'), but does not explicitly state when to use this tool versus alternatives like get_own_profile (for the user's own profile) or search_people (for broader searches). It provides no guidance on prerequisites, exclusions, or error conditions.
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 full burden for behavioral disclosure. It mentions the action ('send a connection request') and a constraint (message length), but fails to disclose critical traits like rate limits, LinkedIn's connection request policies, whether this requires specific permissions, or what happens on success/failure (e.g., pending status, notifications). For a mutation tool with zero annotation coverage, this is a significant gap.
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, efficient sentence that front-loads the core purpose and includes a key constraint. There is zero waste—every word earns its place by clarifying the tool's function and a practical limitation.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., LinkedIn's connection limits, response format), error handling, and does not compensate for the absence of structured safety or output details. For a tool that modifies external state, more context is needed.
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 schema already documents both parameters (profile_urn and message). The description adds minimal value beyond the schema by mentioning the message is 'optional' and has a 'max 300 characters' limit, but doesn't explain parameter interactions or provide additional context like URN format examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('send a connection request') and target ('to a LinkedIn member'), distinguishing it from siblings like 'send_message' (which sends messages to existing connections). It specifies the resource (LinkedIn member) and includes a key constraint (optional personalized message with max 300 characters).
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 for initiating connections on LinkedIn, but provides no explicit guidance on when to use this versus alternatives like 'send_message' (for existing connections) or prerequisites (e.g., needing a valid session). It mentions the optional message feature, which hints at context for personalization, but lacks clear when/when-not rules or named alternatives.
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 full burden. It adds value by disclosing the subscription requirement, which is a behavioral trait (authentication/access need). However, it lacks details on rate limits, pagination behavior beyond the schema, or what the return format looks like, leaving gaps in behavioral context.
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, efficient sentence that directly states the tool's purpose and a key requirement. It is front-loaded with essential information and contains no unnecessary words, making it highly concise and well-structured.
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?
Given the tool's moderate complexity (list retrieval with pagination), no annotations, and no output schema, the description is somewhat incomplete. It covers the basic purpose and a prerequisite but lacks details on output format, error handling, or behavioral nuances, which could hinder effective agent use.
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 description coverage is 100%, with both parameters ('start' and 'count') clearly documented in the schema. The description does not add any meaning beyond this, such as explaining pagination strategies or constraints, so it meets the baseline score for high schema coverage without extra value.
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 verb 'Get' and resource 'all lead lists from Sales Navigator', making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_lead_list_members' or 'get_saved_leads', which might involve related data, so it falls short of a perfect score.
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 provides some context by mentioning 'requires Sales Navigator subscription', which implies a prerequisite for use. However, it does not specify when to use this tool versus alternatives like 'get_lead_list_members' or 'get_saved_leads', nor does it outline any exclusions or specific scenarios for application.
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?
With no annotations provided, the description carries full burden. It indicates this is a read operation ('Get') and specifies authentication context, but lacks details on rate limits, data freshness, or response format. It adds some behavioral context but leaves gaps.
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, clear sentence with no wasted words. It is front-loaded with the core purpose and efficiently conveys all necessary information without redundancy or fluff.
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?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate for basic understanding. However, it lacks details on output structure or behavioral constraints that could aid an agent in proper invocation, leaving room for improvement.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing on tool purpose instead, which aligns with the baseline expectation for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('authenticated user's own LinkedIn profile information'), distinguishing it from sibling tools like 'get_profile' which likely retrieves other users' profiles. It precisely defines scope and ownership.
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 implies usage context by specifying 'authenticated user's own' profile, suggesting it should be used for self-inquiry rather than fetching others' data. However, it does not explicitly name alternatives or state when-not-to-use scenarios.
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

Lindin-Sales-and-Navigator-MCP MCP server

Copy to your README.md:

[![Lindin-Sales-and-Navigator-MCP MCP server](https://glama.ai/mcp/servers/adityaidev/Lindin-Sales-and-Navigator-MCP/badges/card.svg)](https://glama.ai/mcp/servers/adityaidev/Lindin-Sales-and-Navigator-MCP)

Score Badge

Copy to your README.md:

[![Lindin-Sales-and-Navigator-MCP MCP server](https://glama.ai/mcp/servers/adityaidev/Lindin-Sales-and-Navigator-MCP/badges/score.svg)](https://glama.ai/mcp/servers/adityaidev/Lindin-Sales-and-Navigator-MCP)

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/adityaidev/Lindin-Sales-and-Navigator-MCP'

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