MCP server
Plug LinkFetch into Claude Desktop, Cursor, Zed, Continue, or any MCP-aware agent.
The LinkFetch MCP server exposes every public REST endpoint as a typed tool, so any MCP-aware client — Claude Desktop, Cursor, Windsurf, Continue, Zed — can call LinkFetch natively without you writing HTTP plumbing.
Two ways to wire it up
1. Hosted (recommended)
The hosted MCP server runs on https://mcp.linkfetch.io and proxies
to the same REST API. Drop this into your MCP client config:
{
"mcpServers": {
"linkfetch": {
"url": "https://mcp.linkfetch.io",
"transport": "http",
"headers": { "Authorization": "Bearer sk_live_..." }
}
}
}Restart the client. LinkFetch should appear in the tools drawer with one tool per surface.
2. Local bridge (for extension-backed surfaces)
For profile/company/post/group/search/outbound calls — the surfaces that need the user's LinkedIn session — install the LinkFetch Chrome extension and point your MCP client at the local bridge it exposes:
{
"mcpServers": {
"linkfetch-local": {
"url": "http://127.0.0.1:7878",
"transport": "http"
}
}
}The local bridge captures from the user's own browser session and forwards to the API for caching, credit debit, and suppression — same contract as the hosted MCP, but with capture-on-miss working without a separate Capture button.
You can run both concurrently — name them differently
(linkfetch and linkfetch-local) and the agent will pick the one
that handles each tool.
Tools exposed
| Tool | Maps to |
|---|---|
linkfetch_get_profile | GET /v1/profiles |
linkfetch_get_profile_posts | GET /v1/profiles/:slug/posts |
linkfetch_get_company | GET /v1/companies/:slug |
linkfetch_get_company_by_id | GET /v1/companies/by-id/:id |
linkfetch_get_company_posts | GET /v1/companies/:slug/posts |
linkfetch_get_company_employees | GET /v1/companies/:slug/employees |
linkfetch_get_post | GET /v1/posts/:id |
linkfetch_get_post_reactions | GET /v1/posts/:id/reactions |
linkfetch_get_group | GET /v1/groups/:id |
linkfetch_get_group_members | GET /v1/groups/:id/members |
linkfetch_search_people | GET /v1/search/people |
linkfetch_search_companies | GET /v1/search/companies |
linkfetch_search_groups | GET /v1/search/groups |
linkfetch_search_posts | GET /v1/search/posts |
linkfetch_search_jobs | GET /v1/jobs |
linkfetch_get_job | GET /v1/jobs/:id |
linkfetch_get_job_by_url | GET /v1/jobs/by-url |
linkfetch_search_locations | GET /v1/locations/search |
linkfetch_send_connection | POST /v1/outbound/connections |
linkfetch_send_message | POST /v1/outbound/messages |
linkfetch_react_post | POST /v1/outbound/posts/:id/reactions |
linkfetch_comment_post | POST /v1/outbound/posts/:id/comments |
linkfetch_follow_member | POST /v1/outbound/follows/member |
linkfetch_follow_company | POST /v1/outbound/follows/company |
Tool descriptions in the MCP manifest match the catalog descriptions on the /api-endpoints page — same source of truth. When you add a new endpoint to the LinkFetch catalog, the MCP server picks it up on the next deploy.
Provenance in MCP
MCP tool results include the same meta.provenance block as the REST
responses. Agents that need to decide whether to re-fetch should
inspect freshness_days and call again with fresh: true when the
data is too stale for the task.
Auth & limits
The hosted MCP authenticates with the same Bearer key as the REST API.
Rate limits, credits, and the X-Request-Id audit trail all apply.
See Authentication, Pricing, and
Rate limits.