用于访问 Linkedin Sales Navigator No Cookies Required API 的 MCP 服务器。
EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！
🌐 访问 EMCP 平台
📝 注册并登录账号
🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器
🔍 搜索或找到本服务器（bach-linkedin_sales_navigator_no_cookies_required）
🎉 点击 "安装 MCP" 按钮
✅ 完成！即可在您的应用中使用
✨ 零配置：无需手动编辑配置文件
🎨 可视化管理：图形界面轻松管理所有 MCP 服务器
🔐 安全可靠：统一管理 API 密钥和认证信息
🚀 一键安装：MCP 广场提供丰富的服务器选择
📊 使用统计：实时查看服务调用情况
立即访问 EMCP 平台 开始您的 MCP 之旅！
Related MCP server: unipile-linkedin-mcp
这是一个 MCP 服务器，用于访问 Linkedin Sales Navigator No Cookies Required API。
PyPI 包名: bach-linkedin_sales_navigator_no_cookies_required
版本: 1.0.0
传输协议: stdio
pip install bach-linkedin_sales_navigator_no_cookies_requiredpip install -e .# 运行（uvx 会自动安装并运行）
uvx --from bach-linkedin_sales_navigator_no_cookies_required bach_linkedin_sales_navigator_no_cookies_required
# 或指定版本
uvx --from bach-linkedin_sales_navigator_no_cookies_required@latest bach_linkedin_sales_navigator_no_cookies_requiredpython server.py# 安装
pip install bach-linkedin_sales_navigator_no_cookies_required
# 运行（命令名使用下划线）
bach_linkedin_sales_navigator_no_cookies_required此 API 需要认证。请设置环境变量:
export API_KEY="your_api_key_here"变量名 | 说明 | 必需 |
| API 密钥 | 是 |
| 不适用 | 否 |
| 不适用 | 否 |
编辑 Cursor MCP 配置文件 ~/.cursor/mcp.json:
{
"mcpServers": {
"bach-linkedin_sales_navigator_no_cookies_required": {
"command": "uvx",
"args": ["--from", "bach-linkedin_sales_navigator_no_cookies_required", "bach_linkedin_sales_navigator_no_cookies_required"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}编辑 Claude Desktop 配置文件 claude_desktop_config.json:
{
"mcpServers": {
"bach-linkedin_sales_navigator_no_cookies_required": {
"command": "uvx",
"args": ["--from", "bach-linkedin_sales_navigator_no_cookies_required", "bach_linkedin_sales_navigator_no_cookies_required"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}此服务器提供以下工具:
uselessfactsReturns uselessfacts
端点: GET /uselessfacts
uselessfacts_1Returns uselessfacts
端点: POST /uselessfacts
deck_of_cardsReturns deck of cards data
端点: GET /doc
deck_of_cards_1Returns deck of cards data
端点: POST /doc
yes__noReturns yes no data
端点: GET /yesno
yes__no_1Returns yes no data
端点: POST /yesno
foolishReturns foolish data
端点: GET /foolish
foolish_1Returns foolish data
端点: POST /foolish
tv_mazeReturns tv maze data
端点: GET /tv_maze
tv_maze_1Returns tv maze data
端点: POST /tv_maze
pingChecks server health
端点: POST /{ping}
参数:
ping (string) 必需: Example value: ping
ping_1Checks server health
端点: GET /{ping}
参数:
ping (string) 必需: Example value: ping
传输协议: stdio
HTTP 客户端: httpx
MIT License - 详见 LICENSE 文件。
此服务器由 API-to-MCP 工具生成。
版本: 1.0.0
Returns deck of cards data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Returns deck of cards data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Returns foolish data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Returns foolish data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Checks server health
| Name | Required | Description | Default |
|---|---|---|---|
| ping | Yes | Example value: ping |
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.
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.
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.
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.
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.
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.
Checks server health
| Name | Required | Description | Default |
|---|---|---|---|
| ping | Yes | Example value: ping |
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.
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.
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.
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.
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.
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.
Returns tv maze data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Returns tv maze data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Returns uselessfacts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Returns uselessfacts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Returns yes no data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Returns yes no data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0deck_of_cardsdeck_of_cards_1foolishfoolish_1pingping_1tv_mazetv_maze_1uselessfactsuselessfacts_1yesyes_2Multiple 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give AI agents the LinkedIn tools to find, qualify, engage, and follow up with prospects.
Live LinkedIn data for AI agents: profiles, companies, jobs, posts, email finding. No account risk.
Full LinkedIn access for AI agents: leads, messaging, and campaigns with safe limits built in.
LinkedIn data for AI agents: search, profiles, companies, posts. Free key, self-minted, no signup.
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
