A
licenseA
qualityD
maintenanceHigh-performance autonomous MCP server that turns LinkedIn into an API for AI workflows, enabling profile management, job search, content posting, and document generation.
14
1
MIT
LinkAgent
LinkAgent MCP
Universal browser extraction server using Chrome DevTools Protocol. Extract structured data from any website through an extensible plugin system.
How It Works
LinkAgent connects to a running Chromium browser via CDP (Chrome DevTools Protocol) — the same protocol Chrome DevTools uses internally. This means:
No browser automation — reads directly from the live DOM
Indistinguishable from normal browsing — no injected scripts, no headless flags
Works on any site — CDP sees exactly what you see
Cross-browser — Chrome, Edge, Opera, Brave, Vivaldi (anything Chromium-based)
Related MCP server: Ruishu MCP
Architecture
linkagent_mcp/
├── server.py # MCP protocol, tool routing
├── config.py # Environment-based configuration
├── logging.py # Structured logging setup
├── cdp/
│ ├── browser.py # Browser discovery (cross-platform)
│ └── client.py # WebSocket CDP commands
├── core/
│ ├── base.py # BaseExtractor ABC
│ ├── registry.py # Tool registry, dynamic dispatch
│ └── models.py # Data models
└── sites/
└── linkedin/ # LinkedIn extractors
├── extractors/
│ ├── feed.py
│ ├── profile.py
│ ├── company.py
│ ├── jobs.py
│ └── search.py
└── __init__.py # register() functionSee docs/architecture.md for detailed design.
Quick Start
1. Start your browser with CDP
# Windows (Chrome)
chrome.exe --remote-debugging-port=9222
# Windows (Edge)
msedge.exe --remote-debugging-port=9222
# Windows (Opera)
"C:\Users\YourName\AppData\Local\Programs\Opera\opera.exe" --remote-debugging-port=9222
# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
# Linux
google-chrome --remote-debugging-port=9222Log in to LinkedIn (or any target site) in this browser window.
2. Install and run
cd linkagent_mcp
pip install -e .
python -m linkagent_mcp3. Use from any MCP client
The server exposes these tools:
Tool | Description |
| Extract posts from the LinkedIn feed |
| Extract a person's profile |
| Extract a company page |
| Search jobs or extract job details |
| Search for people or companies |
| Navigate to any URL |
| Capture a page screenshot |
| Run arbitrary JavaScript |
| List open browser tabs |
| Scroll the current page |
See docs/tasks.md for detailed tool documentation.
Docker
Run in a containerized Chromium — no local browser needed.
# Build and run
docker compose up -d
# Check logs
docker compose logs -f
# Stop
docker compose downThe container runs headless Chromium with CDP exposed on port 9222. Login sessions persist in a Docker volume (chrome-profile).
Docker + Claude Desktop:
{
"mcpServers": {
"linkagent": {
"command": "docker",
"args": ["compose", "run", "--rm", "linkagent"]
}
}
}Docker + external CDP access:
The CDP port is exposed on localhost:9222. Other tools can connect directly:
import websockets, json
async with websockets.connect("ws://localhost:9222") as ws:
await ws.send(json.dumps({"id": 1, "method": "Target.getTargets"}))
print(await ws.recv())See docs/docker.md for advanced Docker configuration.
Configuration
Set via environment variables or a .env file:
LINKAGENT_CDP_PORT=9222 # CDP debugging port
LINKAGENT_CDP_HOST=127.0.0.1 # CDP host
LINKAGENT_LOG_LEVEL=INFO # DEBUG, INFO, WARNING, ERROR
LINKAGENT_LOG_FILE=linkagent.log # Optional file loggingSee .env.example for all options.
Adding a New Site
See docs/adding-sites.md for a step-by-step guide.
sites/
└── twitter/
├── __init__.py # register(registry) function
└── extractors/
├── __init__.py
└── feed.py # Your extractor1. Create the extractor:
# sites/twitter/extractors/feed.py
from linkagent_mcp.core.base import BaseExtractor
class TwitterFeedExtractor(BaseExtractor):
"""Extract tweets from Twitter/X feed."""
async def extract(self, **kwargs) -> dict:
raw = await self._eval("""
(() => {
const tweets = [];
// ... your extraction logic ...
return JSON.stringify({ tweets });
})()
""")
return json.loads(raw)2. Register it:
# sites/twitter/__init__.py
from linkagent_mcp.core.registry import Registry
from .extractors.feed import TwitterFeedExtractor
def register(registry: Registry):
registry.register(
name="twitter_feed",
extractor_class=TwitterFeedExtractor,
domain="twitter.com",
description="Extract tweets from the feed",
input_schema={"type": "object", "properties": {}},
navigate_url="https://x.com/home",
url_patterns=["/home", "/search"],
)3. Restart the server — it's auto-discovered.
MCP Client Configuration
Claude Desktop
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"linkagent": {
"command": "python",
"args": ["-m", "linkagent_mcp"],
"cwd": "D:\\LinkAgent"
}
}
}Cursor / Windsurf
Add to your MCP settings:
{
"linkagent": {
"command": "python",
"args": ["-m", "linkagent_mcp"],
"cwd": "D:\\LinkAgent"
}
}Development
# Install dev dependencies
pip install -e .
# Run with debug logging
LINKAGENT_LOG_LEVEL=DEBUG python -m linkagent_mcp
# Run tests
python tests/test_live.pyRoadmap
See docs/roadmap.md for the full roadmap.
Current (v0.1.0)
Universal CDP-based extraction framework
Plugin system with auto-discovery
5 LinkedIn extractors (feed, profile, company, jobs, search)
5 browser control tools
Cross-platform browser detection
Environment-based configuration
Structured logging
Next (v0.2.0)
Robustness — Auto-reconnection, health checks, error recovery
More data — Pagination, expanded sections, media extraction
More sites — Twitter/X, GitHub, Reddit, Instagram
Better output — Data storage, export formats, caching
Future Goals
Self-healing selectors — Automatically adapt to DOM changes
Write operations — Safe, controlled posting and messaging with human approval
Multi-browser — Multiple profiles, remote browsers, Docker support
Scheduling — Cron-like extraction, event-driven alerts
Analytics — Trend analysis, network analysis, competitive intelligence
Platform — Visual extractor builder, marketplace, cloud hosting
What We Want to Overcome
Problem | Current State | Goal |
Fragile selectors | Manual updates when LinkedIn changes | Self-healing, automatic adaptation |
Read-only | Cannot post, message, or interact | Controlled writes with approval |
Single browser | One profile, one session | Multiple browsers and profiles |
No scheduling | Manual extraction only | Cron jobs, event-driven alerts |
No storage | JSON output only | SQLite/PostgreSQL, CSV export |
No testing | Manual testing only | Snapshot tests, selector monitoring |
Deployment | Requires local browser | Docker, cloud, headless mode |
See docs/limitations.md for known issues.
Documentation
Architecture — System design and data flow
File Reference — What every file does
Tasks — Tool documentation and return values
Limitations — Known issues and constraints
Adding Sites — Step-by-step guide
Selector Strategy — How we pick stable DOM elements
Roadmap — Future plans and goals
License
MIT — see LICENSE.
Available Tools
16 toolsclickA
Click an element on the page by CSS selector. Triggers native mouse events (mousedown, mouseup, click).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the element to click |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that native mouse events (mousedown, mouseup, click) are triggered, providing behavioral context beyond the name. No annotations present, so description carries the burden.
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 purpose and detailed with event info. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers the simple tool (1 param, no output schema). Could mention error handling or visibility checks but not essential for basic usage.
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% (one parameter described as 'CSS selector'). Description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action (click), target (element by CSS selector), and method (triggers native mouse events). Distinguishes from sibling tools like send_keys or get_text.
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?
Implies usage for clicking elements but provides no when-to-use or when-not-to-use guidance, nor mentions alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
execute_jsB
Execute arbitrary JavaScript in the current page via CDP.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JavaScript to execute |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden; it lacks details about return values, potential side effects, security implications, or whether the script executes asynchronously.
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?
One sentence, appropriately sized; could be improved with front-loading of purpose, but no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is adequate but lacks return value info and error handling context, especially given no annotations or output schema.
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% (parameter has description), and the description adds no additional meaning beyond the schema, so baseline 3.
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 it executes arbitrary JavaScript in the current page via CDP, a specific verb and resource, and distinguishes from sibling tools like click, type_text, etc.
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, nor any context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_textB
Get the visible text content of an element by CSS selector.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the element |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions 'visible text' but fails to specify behavior on element not found, multiple matches, or performance implications. The agent must infer these details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's function.
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 (one parameter, no output schema), the description is marginally adequate. However, it does not specify the return type (expected string) or error handling, which would improve completeness.
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% (one parameter fully described). The description adds no new meaning beyond the schema, as 'by CSS selector' repeats the parameter description. Baseline 3 is appropriate.
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'), the target ('visible text content'), and the mechanism ('by CSS selector'). It distinguishes itself from siblings like 'get_value' (which gets attribute values) and 'send_keys' (which sends keystrokes).
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 (e.g., get_value, wait_for_element). It does not mention prerequisites or situations where this tool is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_valueB
Get the current value of an input/textarea element.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the input element |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states it gets the value, but does not disclose behavior for missing elements, multiple matches, or return type. Basic purpose stated but insufficient behavioral details.
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, no wasted words. Perfectly concise for a simple tool.
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 low complexity (single parameter, no output schema), the description is minimally adequate. However, it lacks details on return type, error handling, or specific element types beyond input/textarea, which would improve completeness.
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% for the single parameter 'selector'. The description adds no extra meaning 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?
Clearly states the verb 'get' and the resource 'current value of an input/textarea element'. Distinguishes from sibling 'get_text' which likely retrieves text content, and 'send_keys' which sends input.
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_text' or when it should not be used. User must infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_companyB
Extract a LinkedIn company page. Provide company name or navigate first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| company_name | No | LinkedIn company name (from URL /company/name) |
TDQS
B3.2/5.0
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 describes an 'Extract' operation, implying a read-only action, but does not mention potential issues like missing company pages, rate limits, or authentication requirements. The behavioral traits are insufficiently specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no unnecessary words. It is front-loaded with the key action and provides all essential information in a compact form. Every sentence serves a purpose.
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 has one parameter (fully described) and no output schema or annotations. However, the description fails to specify what the tool returns (e.g., company details, profile data) or how the 'navigate first' alternative works. For a tool with these characteristics, more detail on outputs and usage flow is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the sole parameter has a description). The description adds context ('Provide company name or navigate first'), indicating the parameter is optional and can be omitted if navigation occurs first. This adds marginal value beyond the schema, but the baseline 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 specifies the verb 'Extract' and the resource 'LinkedIn company page', making the tool's purpose clear. It distinguishes from sibling tools like linkedin_profile (for people) and linkedin_feed (for feed), though not explicitly, but the context of company pages is sufficiently unique.
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 basic guidance ('Provide company name or navigate first'), implying two modes of use. However, it does not explicitly state when to use this tool versus alternatives like linkedin_search or linkedin_profile, nor does it give exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_feedB
Extract posts from the LinkedIn feed. Returns authors, headlines, post text, links, and engagement metrics.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only lists output fields but fails to mention read-only nature, auth requirements, rate limits, pagination, or any data freshness constraints.
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 sentence with no wasted words. It front-loads the action and data returned. Could be slightly more structured but remains efficient.
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 0 parameters, no annotations, and no output schema, the description is insufficiently complete. It omits critical context like pagination, authentication needs, and whether the feed is personalized or general.
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, so the description naturally adds meaning beyond the schema by detailing the returned fields. However, it could be improved by noting any default behavior or filters.
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 verb 'Extract', the resource 'posts from LinkedIn feed', and specifies what is returned (authors, headlines, post text, links, engagement metrics). It effectively distinguishes from sibling tools like linkedin_profile which focuses on profile data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like linkedin_search or linkedin_profile. There are no explicit contexts, exclusions, or conditions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_jobsB
Search jobs or extract job details. Provide keyword for search, or job_id for detail.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No | LinkedIn job ID (from URL /jobs/view/{id}) | |
| keyword | No | Job search keyword |
TDQS
B3.3/5.0
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 only states 'search' or 'extract' but does not disclose behavioral traits such as whether it is read-only, rate limits, error handling, or response size. This lack of detail 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 extremely concise: two sentences, no wasted words. It is front-loaded with the action and then the parameter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple search/detail tool with only two parameters, but it lacks information about return format or whether both parameters can be used together. Without an output schema, the agent might not know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description reiterates the parameter purposes (keyword for search, job_id for detail). It does not add new meaning 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 clearly states the tool searches jobs or extracts details, with parameters for keyword or job_id. It distinguishes from sibling tools like linkedin_search, linkedin_profile, etc., which focus on other aspects. However, it could be more specific about the output (e.g., list vs. single result).
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 basic usage context: use 'keyword' for search, 'job_id' for details. It does not explicitly state when not to use this tool or compare to alternatives like linkedin_search, which might offer broader search capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_profileB
Extract a LinkedIn person profile. Provide username or navigate to profile first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| username | No | LinkedIn username (from URL /in/username) |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states 'Extract' indicating a read operation but does not disclose what data is returned, any limitations, authentication requirements, or error conditions. The lack of output schema further leaves agents unaware of the response format.
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 extremely concise, consisting of two sentences that are front-loaded and waste no words. Every sentence adds meaningful instruction (what it does and how to use it), making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is incomplete. It does not explain what the extracted data contains, any pagination, or error states. An agent cannot determine the return format or handle edge cases without additional 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?
The input schema fully describes the single parameter 'username' (100% coverage), achieving baseline 3. The description adds value by clarifying that providing a username is optional and that the tool can work from the current page, but this context is only marginally beyond the schema's existing 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 verb 'Extract' and the resource 'LinkedIn person profile', making the tool's purpose evident. It implicitly differentiates from sibling tools like linkedin_company and linkedin_feed by specifying 'person profile', but lacks explicit sibling differentiation.
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 usage context by mentioning two methods: provide username or navigate first. However, it does not explicitly state when to use this tool over alternatives or exclude scenarios (e.g., 'use linkedin_company for company profiles'), leaving the decision somewhat inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_searchC
Search for people or companies on LinkedIn.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Search keyword | |
| search_type | No | Type of search: people or company | people |
TDQS
C2.7/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not mention authentication needs, result behavior, side effects (e.g., page navigation), or whether it is read-only. The description is too sparse to inform agent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core purpose. However, it could be slightly more informative 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?
For a search tool with no output schema, the description should hint at return values or behavior (e.g., list of results, new page). It misses this and other context like error handling or pagination, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are well-described in the schema. The description adds no additional meaning beyond what is already in the schema. 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 clearly states it searches for people or companies on LinkedIn. However, it does not differentiate from sibling tools like linkedin_profile or linkedin_company, which may perform similar lookups but with more specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives (e.g., linkedin_profile for individual profiles). There are no exclusion criteria or context hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tabsA
List all open browser tabs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic function. It does not disclose that the operation is read-only or other behavioral traits, though for a simple list tool this is adequate.
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, no redundancy, immediately conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters or output schema, the description is complete and sufficient.
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?
No parameters exist, and schema coverage is 100%. Baseline 4 for zero parameters, description adds no param info but none needed.
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 verb 'List' and the resource 'open browser tabs', distinguishing it from sibling tools like click, navigate, etc., which perform different actions.
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?
No explicit guidance on when to use this tool versus alternatives. Usage is implied by its name, but no when-not or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scroll_pageB
Scroll the current page up or down.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pixels | No | Pixels to scroll | |
| direction | No | down |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like whether the scroll is smooth, incremental, or what happens at page boundaries. The description is minimal and assumes prior knowledge.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that conveys the core functionality without unnecessary words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple scroll tool, the description is adequate but lacks information about units (pixels typical), behavior when scrolling beyond limits, and whether it works in all contexts. Could be improved.
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 already documents default values and enum for direction. The description adds no extra meaning. With 50% schema coverage, the description could have compensated for the missing parameter description (direction) but did not.
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 (scroll) and the target (current page) with the axis (up or down). It is specific and distinct from sibling tools like click or navigate.
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 such as execute_js for scroll or send_keys for arrow keys. Missing context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_keysB
Send keyboard key presses (e.g. Enter, Tab, Escape). Useful for submitting forms, navigating, or closing modals.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| keys | Yes | List of key names to press (e.g. ['Enter'], ['Tab', 'Enter']) |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Does not disclose whether keys are sent sequentially or simultaneously, effect on focus, or support for modifiers. Incomplete for an action tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Purpose and examples are front-loaded. Could be slightly tighter but efficient overall.
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?
Simple tool with one parameter, but missing details on key name conventions, modifiers, and focus context. Adequate for basic use but not fully self-contained.
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% and description repeats examples from schema. No additional meaning added beyond what the schema provides. Baseline score due to high 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?
Clearly states sending keyboard key presses with examples (Enter, Tab, Escape) and use cases (submitting forms, navigating, closing modals). Distinguishes from sibling tools like click, type_text, navigate.
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?
Provides context (submitting forms, navigating, closing modals) but does not explicitly state when not to use or compare with alternatives. Implied use cases but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
take_screenshotA
Take a screenshot of the current page.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the action without disclosing return format, side effects, or behavioral traits like viewport capture.
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?
Single sentence, front-loaded with the action. However, it is too minimal and omits essential 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?
Tool has no output schema and no annotations; description fails to specify return value (e.g., base64 image, file path) or scope (e.g., viewport only).
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?
No parameters exist, so schema coverage is 100%. Baseline is 4, and description adds no parameter info since none needed.
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 (take a screenshot) and the resource (current page), which is specific and distinguishes it from sibling tools like click or navigate.
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?
No explicit guidance on when to use this tool versus alternatives; usage is implied but not detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
type_textA
Type text into an input field or textarea by CSS selector. Focuses the element and types character by character.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to type | |
| clear | No | Clear existing text before typing | |
| delay_ms | No | Delay between keystrokes in ms | |
| selector | Yes | CSS selector for the input element |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains that the tool focuses the element and types character by character, but does not disclose other behaviors such as whether it waits for the element to be visible, scrolls into view, or handles errors. The delay parameter is mentioned in the schema but not in the description, though the description implies character-by-character input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and then a brief detail. Every word adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with full schema coverage and no output schema, the description is mostly sufficient. It covers the primary action but does not mention return value (likely void) or error handling, which is acceptable for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it repeats the typing behavior but does not elaborate on the clear or delay parameters beyond what the schema already provides.
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 tool types text into an input field or textarea using a CSS selector, and specifies that it focuses the element and types character by character. This distinguishes it from sibling tools like get_text (read-only) and send_keys (which may not type character by character).
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 does not provide any guidance on when to use this tool versus alternatives like send_keys. It lacks context about prerequisites (e.g., element must exist and be visible) and does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wait_for_elementA
Wait until an element appears on the page (by CSS selector). Useful after navigation or clicking.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector to wait for | |
| timeout_ms | No | Max wait time in ms |
TDQS
A3.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Does not disclose behavior on timeout/failure, nor any side effects. With no annotations, the description carries full burden but adds no behavioral context beyond the basic operation.
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?
Efficient two-sentence structure, front-loaded with core purpose and contextual usage hint.
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?
Provides essential purpose and usage context, but lacks return value/error behavior. With no output schema, description should clarify what the tool returns or throws.
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 already describes both parameters fully; description adds no additional meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States explicit purpose: waiting for an element by CSS selector. Clearly distinguishes from action-oriented siblings like click or type_text.
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?
Provides explicit usage context ('Useful after navigation or clicking'), but lacks when-not-to-use or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
16 tool updates
v1.0.0- First observed
click - First observed
execute_js - First observed
get_text - First observed
get_value - First observed
linkedin_company - First observed
linkedin_feed - First observed
linkedin_jobs - First observed
linkedin_profile - First observed
linkedin_search - First observed
list_tabs - First observed
navigate - First observed
scroll_page - First observed
send_keys - First observed
take_screenshot - First observed
type_text - First observed
wait_for_element
TDQS
A3.5/5.0
Disambiguation5/5
Each tool has a clear and distinct purpose: general browser automation tools (click, type, scroll, etc.) are separate from LinkedIn-specific tools (feed, profile, company, jobs, search). There is no ambiguity between get_text and get_value, or between type_text and send_keys.
Naming Consistency4/5
Tools follow a predictable snake_case pattern, but general tools use verb_noun (e.g., send_keys, navigate) while LinkedIn tools use domain_noun (e.g., linkedin_feed, linkedin_search). This slight inconsistency within the set prevents a perfect score.
Tool Count5/5
16 tools is well-scoped for a LinkedIn automation server. It provides a sufficient set of general browser interactions and dedicated LinkedIn scrapers without being excessive or sparse.
Completeness4/5
The tool set covers core LinkedIn data extraction (feed, profile, company, jobs, search) and essential browser actions. Minor gaps exist (e.g., no posting, messaging, or list connections), but these are likely out of scope for a scraping-focused server.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
Live LinkedIn data for AI agents: profiles, companies, jobs, posts, email finding. No account risk.
- LinkMCPOAuthio.linkmcp
Hosted MCP server for LinkedIn: 31 tools for profiles, search, messaging, posts, enrichment.
LinkedIn outreach MCP server — 19 tools for AI agents to prospect, sequence, and manage contacts.
Related MCP Servers
- FlicenseAqualityAmaintenanceAn MCP server that bridges LLMs with dynamic real-world data by leveraging Chrome DevTools Protocol to intercept and reconstruct network traffic, enabling AI agents to extract high-quality structured data from complex web environments.388-
- AlicenseNot gradedqualityCmaintenanceMCP server for LinkedIn automation that enables AI agents to perform LinkedIn actions (search, inbox, feed, jobs, etc.) safely with human-like evasion and two-phase commit preview.132MIT
- AlicenseNot gradedqualityCmaintenanceMCP server for programmable LinkedIn automation via Playwright, offering 20 tools for profile management, messaging, feed interaction, and job searching through real browser automation.29MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/karthik-ak-Git/LinkAgent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server