LinkedIn Sales Navigator No Cookies Required MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation1/5
Multiple tools are exact duplicates (e.g., uselessfacts vs uselessfacts_1, deck_of_cards vs deck_of_cards_1), providing no way to distinguish between them. The ping tools are also duplicated. An agent cannot reliably choose between these tools.
Naming Consistency2/5
Tool names are in snake_case but follow no discernible pattern; verbs like 'returns', 'checks' are not consistently used, and numbered suffixes (e.g., _1, _2) appear arbitrary. There is no verb_noun structure across the set.
Tool Count2/5
The server has 12 tools, but nearly half are duplicates, leaving only ~6 unique functions. For a LinkedIn Sales Navigator server, this count is inflated with irrelevant or redundant tools, making the set feel bloated yet shallow.
Completeness1/5
The server's stated purpose is LinkedIn Sales Navigator, yet none of the tools relate to that domain. There are no lead search, account management, or messaging capabilities—the surface is entirely unrelated to the intended use case.
Average 2.2/5 across 11 of 12 tools scored. Lowest: 1.6/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?
With no annotations and no meaningful description, the tool's behavior is entirely opaque. The phrase 'returns foolish data' discloses nothing about side effects, permissions, rate limits, or return characteristics.
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 a single vague sentence, which is not conciseness but severe under-specification. It provides no structural value and leaves the reader with no useful information.
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?
Given the absence of annotations and output schema, the description carries the full burden of explaining the tool. It completely fails to do so, offering no context about what 'foolish data' is, how it is returned, or why an agent would invoke it.
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 and the empty schema already fully documents that. No additional parameter information is needed, so the description does not need to compensate. Baseline 4 for 0-parameter tools.
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 'Returns foolish data' merely restates the tool name 'foolish' with no verb or resource specification. It fails to convey what the tool actually does, what 'foolish' means, or how it differs from siblings like uselessfacts or yes.
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 provided on when to use this tool versus alternatives. The description gives no context for appropriate use, prerequisites, or exclusions.
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, and the description discloses no behavioral traits. It does not state whether the operation is read-only, what data is returned, or any side effects or limitations.
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 under-specified. The single sentence 'Returns tv maze data' does not earn its place as it merely repeats the tool name and provides no useful information, similar to the 'Process' example.
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 parameter details, the description is the sole source of context. It is completely inadequate, offering no details about the data returned, usage, or behavior, making it impossible for an agent to understand the tool.
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 the schema is empty and provides no information. According to the baseline for 0 params, a score of 4 is appropriate since there is no parameter information to add beyond the schema.
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 'Returns tv maze data' is essentially a tautology, restating the tool name without specifying what kind of data or what resource is involved. It does not clearly distinguish the tool from sibling tools like tv_maze_1.
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 provided on when to use this tool versus alternatives such as tv_maze_1. The description lacks any context about intended use cases or scenarios where this tool is preferable.
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 full responsibility for disclosing behavior, but it only states a generic return of data. No mention of side effects, safety constraints, rate limits, or what the response looks like. This is a significant transparency gap.
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 a single sentence, which is brief, but it is under-specified to the point of being unhelpful. It does not earn its place as it adds no substantive information beyond the tool name.
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?
Given the simple schema (no params, no output schema), the description still fails to explain what data is returned, in what format, or any behavioral details. It is completely inadequate for an agent to know what to expect from this tool, especially with a sibling 'tv_maze' that likely has richer documentation.
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 the input schema fully documents the absence of inputs. Per the guideline, 0 params receives a baseline of 4. The description adds no parameter details, but none are needed.
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 'Returns tv maze data' is essentially a restatement of the tool name (tv_maze_1) with a generic verb. It identifies the resource but lacks specifics about what kind of TV Maze data (shows, episodes, people, etc.), making it vague and indistinguishable from the sibling tool 'tv_maze'.
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. The description provides no context about use cases, prerequisites, or exclusions, leaving the agent without any 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?
With no annotations, the description carries the full burden of behavioral disclosure. It says nothing about output format, randomness, rate limits, or any side effects, which is a significant gap for any tool.
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 does not earn its place as it adds no information beyond the tool name. It is under-specified rather than appropriately concise.
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?
Given the lack of annotations, output schema, and any behavioral details, the description is wholly incomplete. Even for a simple fact-returning tool, it should state whether the fact is random, how it is returned, or any limitations.
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 the input schema provides complete coverage. The description does not need to explain parameter meaning, and the baseline of 4 applies due to the vacuous schema coverage.
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 'Returns uselessfacts' essentially restates the tool name without adding specificity. It fails to distinguish this tool from its sibling 'uselessfacts_1' and does not clarify whether facts are random, curated, or how they are delivered.
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 provided on when to use this tool versus alternatives. It does not mention any context or exclusions, leaving the agent to guess.
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 disclose behavior. It does not mention whether the output is random, deterministic, or how to interpret the result. There is no information about side effects, return format, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than conciseness. It conveys no actionable detail and does not earn its place as a useful 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?
With no annotations, no output schema, and a misleadingly simple name, the description is inadequate. It fails to explain the tool's behavior, output, or purpose, making it nearly impossible for an agent to decide whether to invoke it.
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 the description does not need to explain parameter semantics. The empty input schema is fully covered (100%). Baseline for 0 params is 4; no deduction is necessary.
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 'Returns yes no data' is extremely vague. It does not specify what 'yes no data' means (e.g., a random boolean, a decision generator, or a set of two values). It fails to distinguish this tool from sibling tools like 'yes' or 'foolish'.
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. No mention of scenarios, prerequisites, or exclusions. The description offers 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states that it returns 'yes' and 'no data', which is the bare minimum about the return value. It does not mention whether the operation is read-only, has side effects, requires auth, or any other behavioral detail. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. The phrase 'Returns yes no data' is grammatically awkward and ambiguous due to missing punctuation. It does not provide a clear, structured explanation and could be clearer even in one sentence.
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 trivial tool with no parameters and no output schema, the description still lacks essential context. It doesn't explain what the tool is for, how it fits into a workflow, or what 'yes' represents. It is barely more informative than the tool name itself. Given the absence of annotations and output schema, the description should compensate, but it doesn't.
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 per the rubric, a 0-parameter tool receives a baseline of 4. The description does not need to add parameter semantics because there are none. The schema already covers an empty object with 100% coverage.
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 'Returns yes no data' is not much more than a tautology of the tool name 'yes'. It does start with a verb 'Returns', but the object is just the tool's own name, and the meaning of 'no data' is ambiguous (whether it means returns 'yes' with no associated data, or returns a yes/no answer). It does not distinguish from sibling tools like 'ping' or 'foolish'.
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 provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions. The description is entirely silent on usage 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?
With no annotations provided, the description must disclose behavioral traits. It only says 'returns foolish data' and provides no information about side effects, permissions, rate limits, output structure, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but this is under-specification rather than conciseness. It lacks informative content and reads as a placeholder, offering no value beyond restating the tool's name.
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?
Given the minimal description, no annotations, no output schema, and empty input schema, the tool is completely underspecified. The agent receives no meaningful information to understand the tool's purpose, behavior, or expected output.
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 the schema fully covers the input surface. The baseline is 4 for 0-parameter tools, and the description does not need to add parameter details, though it also fails to clarify what the returned data represents.
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 vague and tautological, stating it 'returns foolish data' without specifying what resource or functionality it accesses. It fails to distinguish itself from the sibling tool 'foolish', making it unclear what unique purpose this tool serves.
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 the many sibling tools listed. No context, prerequisites, or alternative tools are mentioned, leaving the agent without direction on 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 must fully disclose behavioral traits such as read-only behavior, return format, or side effects. The phrase 'Returns deck of cards data' only indicates that the tool returns something; it does not disclose what the data looks like, whether the deck is shuffled, or any other relevant behavior. This is a significant gap for a tool with no structured metadata.
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, concise sentence with no unnecessary words. It is front-loaded with the verb 'Returns' and the resource. However, it is under-specified, offering minimal value beyond a very basic summary. While it is concise, the brevity contributes to its vagueness, so a slightly lower score is warranted.
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 (no parameters and no output schema), the description still does not convey enough context. It fails to specify the structure or content of the returned 'deck of cards data'. Without an output schema, the description should provide more detail about the return value, but it does not. The tool's completeness is inadequate for an agent to know what to expect.
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 the description has no need to explain parameter semantics. According to the rubric, a baseline of 4 applies when there are no parameters. The description adds no parameter information, but none is required, so the baseline score holds.
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 uses the verb 'Returns' and specifies the resource as 'deck of cards data', which clearly states the tool's basic function. However, it is vague about what specific data is returned (e.g., card values, suits, shuffled deck), and it does not differentiate from sibling tools that also return data. Therefore, it is a clear but generic purpose.
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 does not mention any prerequisites, typical use cases, or exclusions. There is no context to help an agent decide between this tool and its siblings, so it lacks any usage framework.
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 states that the tool returns uselessfacts, but does not clarify the output format, whether the facts are random, if there are any rate limits, or any other behavioral traits. The minimal wording provides almost no transparency.
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, concise sentence that directly states the tool's purpose. It is front-loaded and every word earns its place. However, it is so brief that it borders on under-specification, although for a parameterless tool, this level of brevity is not unreasonable.
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 lacks annotations, output schema, and parameters, so the description must provide all context. 'Returns uselessfacts' is too vague: it does not explain what constitutes a useless fact, what the response structure looks like, or any usage caveats. The description is insufficient for an agent to fully understand the tool's 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 zero parameters, and the schema is trivially complete with 100% coverage. Per the rubric, the baseline for 0 parameters is 4, and the description does not need to explain parameter semantics since there are none. The description adds no param info, but this is acceptable given the empty 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 'Returns uselessfacts' clearly states the tool's purpose with a specific verb ('Returns') and resource ('uselessfacts'). However, it does not differentiate from the sibling tool 'uselessfacts' (without the _1 suffix), which likely serves a similar or identical function.
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. The description does not mention any context, exclusions, or use cases, leaving the agent without direction on 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, the description carries the full burden of disclosing behavior. It only states that data is returned, without mentioning any details about the return format, side effects, or whether the deck is shuffled or generated. This leaves significant ambiguity.
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 a single short sentence with no filler, which is concise. However, it is under-specified and lacks any structural richness that would make it a model of clarity, so it does not earn a higher score.
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 has no output schema and a similarly named sibling, the description leaves the agent in the dark about what 'deck of cards data' actually contains or how it differs from alternatives. It is too sparse to be considered complete 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 tool has zero parameters and the schema coverage is vacuously 100%. The description adds a minimal but useful note that no input is needed and data is simply returned, meeting the baseline for zero-parameter tools.
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 the specific verb 'Returns' and names the resource 'deck of cards data', making the core function clear. However, it does not distinguish itself from the sibling tool 'deck_of_cards', so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'deck_of_cards'. The description provides no context about suitability, 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 must fully disclose behavior. It states 'checks server health' but doesn't explicitly confirm it's a read-only operation, describe the response format (e.g., success/failure indicators), or mention any side effects or requirements. The description is too sparse to inform the agent about expectations.
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 three-word sentence, 'Checks server health', with no unnecessary words. It is extremely concise and front-loaded, earning full marks for brevity.
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 the tool's simplicity, the absence of an output schema and annotations leaves return values and behavioral context unspecified. The description doesn't explain what a healthy response looks like or how to handle errors, making it incomplete for an agent to invoke confidently.
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, as the 'ping' parameter includes 'Example value: ping', which is a syntax example rather than semantic meaning. The tool description adds no parameter context beyond the schema, so baseline 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 uses a specific verb 'checks' and resource 'server health' to clearly state the tool's function. However, it doesn't differentiate from sibling tool 'ping_1' or explain variations, so it's clear but not fully distinguishing.
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 'ping_1' or other sibling tools. No context, prerequisites, or exclusions are mentioned, leaving the agent to infer applicability.
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 burden for behavioral disclosure. It only states 'Checks server health' without specifying what the check entails, whether any side effects occur, or what response format is returned. This is minimal transparency.
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, short sentence with no wasted words. It is front-loaded and to the point, though it could benefit from more detail without becoming verbose.
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 the tool's low complexity, the description is insufficient for correct selection because there is a sibling tool with the same name ('ping'). No differentiation or context is provided, and no output schema or annotation exists to fill the gap.
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% for the single parameter 'ping', which includes an example value. The description adds no extra meaning beyond the schema, 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?
Description uses a clear verb 'Checks' and resource 'server health', making the tool's purpose immediately understandable. However, it does not distinguish from the sibling tool 'ping' with nearly identical name and likely identical purpose.
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 sibling 'ping' or other alternatives. The description simply states the function without any context, exclusions, or preference.
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:

[![bachai-linkedin-sales-navigator-no-cookies-required MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-linkedin-sales-navigator-no-cookies-required/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-linkedin-sales-navigator-no-cookies-required)

Score Badge

Copy to your README.md:

[![bachai-linkedin-sales-navigator-no-cookies-required MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-linkedin-sales-navigator-no-cookies-required/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-linkedin-sales-navigator-no-cookies-required)

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/bachai-linkedin-sales-navigator-no-cookies-required'

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