Building Fintalio in Public: What We Learned Shipping a LinkedIn MCP Server

#TL;DR

I’m Ilyas, the founder of Fintalio. We shipped a LinkedIn MCP server in May 2026, and the launch taught us more in eight weeks than the prior six months of planning did. The Model Context Protocol crossed an inflection point in late 2024 when Anthropic open-sourced it (Anthropic, 2024), and by spring 2026 the registry was tracking hundreds of public servers (Model Context Protocol, 2026). Building inside that wave was equal parts exhilarating and humbling. This is the unvarnished version of what worked, what didn’t, and what we’re fixing next.

If you want the product itself, the pillar guide explains how a LinkedIn MCP server works in practice. This post is for the builders.

#Why we bet on a LinkedIn MCP server in 2026

We bet on a LinkedIn MCP server because the timing finally lined up. By Q1 2026 the MCP registry tracked over 1,000 public servers, up from roughly 100 at the start of 2025 (Model Context Protocol, 2026). Developer survey data showed 76% of professional developers using or planning to use AI tools in their workflow (Stack Overflow Developer Survey, 2024). LinkedIn was the integration everyone wanted and nobody enjoyed building. Three signals converged at once.

The first signal was protocol maturity. MCP shipped in November 2024, and by mid-2025 the host ecosystem stopped being “Claude Desktop only.” Cursor, Windsurf, Claude Code, and a parade of open-source agent frameworks were all speaking the same wire format. That breadth of clients made building a single server economically defensible. Write once, ship to every host.

The second signal was demand pull. Every founder I talked to in late 2025 was wiring some LinkedIn workflow into their product. Some were doing it well. Most were copying brittle Puppeteer scripts off GitHub and hoping nothing broke before the demo. The pain was unevenly distributed but loud.

The third signal was the regulatory floor finally being legible. We had a year of public LinkedIn ToS updates and a body of case law from the hiQ v. LinkedIn saga to work from. Building compliance-first stopped being theoretical. We wrote a separate piece on the LinkedIn ToS landscape for AI automation once we had clarity on what was actually defensible.

We did not bet on this because the SEO was easy. There was a niche demand signal for “linkedin mcp” with negligible competition, and that helped. But the demand was not the thesis. The thesis was: every AI agent that does real work needs LinkedIn, and the developers building those agents would pay for a clean abstraction.

#What we actually built (without the marketing varnish)

What we shipped is a Laravel-hosted MCP server exposing 19 LinkedIn tools and 3 resources over a Sanctum-authenticated /mcp endpoint, with a hosted OAuth bridge handling LinkedIn session lifecycle. Anthropic’s MCP spec calls for tools, resources, and prompts; we ship the first two (modelcontextprotocol.io, 2024). One plan, €69/mo, MCP bundled. No free tier, no usage-based meter exposed yet.

The shape of the tool surface matters more than the count. The 19 tools split into nine read operations (ListContacts, GetContact, ListContactGroups, ListSequences, GetSequence, ListSequenceTemplates, GetSequenceTemplate, ListVariables, GetAccountStatus), nine write operations (mostly contact and sequence mutations plus CSV parse and commit), and one execute (LaunchSequence). We deliberately did not ship a SearchProfiles or ReadInbox tool at launch. More on that in the mistakes section.

#The auth flow

Authentication runs on Laravel Sanctum personal access tokens. A user generates a token in Settings, pastes it into their Claude Desktop or Cursor config, and the MCP host signs every JSON-RPC call. We rate-limit at 120 requests per minute per token, which is plenty for a single agent and noisy enough to catch runaway loops early.

LinkedIn session management sits behind Fintalio’s hosted auth wizard. The user connects their account once through the first-party auth flow. The compliant LinkedIn relay holds the session, refreshes it, and applies per-account daily action limits before any write call reaches LinkedIn. The agent never sees a cookie. We unpacked the design choices in the deep-dive on auth, rate limits, and audit logs.

#The boring infrastructure parts

A lot of what we built is dull. Idempotency keys on every send. Per-account throttle overrides for power users with verified accounts. CSV import in two stages (parse, then commit) so an LLM can preview before committing. Audit logs on every write tool call, with the calling token id and the human-approval timestamp. None of it is novel. All of it is necessary.

In our experience, the boring parts are 70% of the work and 100% of the difference between a demo and a product.

#Three things we got wrong

#1. We over-engineered the schema before talking to enough users

Our first contact model had 14 fields and a polymorphic relationship to support “any kind of LinkedIn entity, banker or recruiter or founder or hiring manager.” We thought generality was a feature. It wasn’t. Early users all imported simple CSVs with name, company, linkedin_url, email. The polymorphic tables sat empty.

We spent three weeks ripping out the abstraction and collapsing to a flat Contact model with a custom_data JSON column for the edge cases. Faster queries, simpler MCP tool signatures, fewer questions in the Discord. The lesson is older than software, but it bit us anyway. Start concrete. Generalize when the second customer asks for the same exception.

#2. We misjudged the developer auth UX

I assumed our users were comfortable pasting a Sanctum bearer token into a JSON config. About half were, and half hit a wall. The half that hit the wall were not less technical. They were experienced devs who’d been spoiled by OAuth and didn’t want to manage a long-lived secret in a plaintext file.

We’re still working through this. The current half-fix is a one-paste config block we render in the dashboard, so the user copies a single JSON snippet instead of assembling one from a token and an endpoint URL. The proper fix, which is on the roadmap, is OAuth Device Flow for MCP clients that support it.

#3. We launched without an Authorize Tool UX inside the host

Claude Desktop and Cursor both render a permission prompt before invoking a write MCP tool. That UX is host-controlled, not server-controlled, and we treated it as table stakes. It isn’t. Some hosts auto-approve “safe” tools after a single confirmation. Some don’t show the approval gate at all in headless mode. We had to add a server-side requires_approval: true flag on every write tool, plus an in-Fintalio approval queue that holds writes until a human clicks send.

The hard lesson: never let the host be the only safety layer. Defense in depth is not optional when the worst case is a runaway agent triggering 200 LinkedIn DMs at 3 AM.

#Three things we got right

#1. Compliance-first design beat compliance-retrofit

We decided early that every write tool would land in a queue, every send would be audit-logged with token id and timestamp, and per-account daily limits would be hard caps rather than soft warnings. That cost us shipping velocity. It also meant when a prospect’s legal team asked “how do you stay inside LinkedIn’s ToS?” we had an actual answer with code paths to point at, not a slide deck.

The number of conversations that closed because we could send a one-page architecture diagram of the audit layer surprised me. Trust compounds faster in this category than I expected.

#2. Tool surface shaped by the agent loop, not the REST API

The temptation when you wrap a service is to expose one MCP tool per REST endpoint. We resisted that. Composing five low-level calls in the right order is exactly the kind of thing LLMs do badly under cost pressure. So our tools are agent-shaped: LaunchSequence does what its name says, not CreateCampaign then AttachTemplate then LinkContacts then Start.

The clearest signal that this was right: the prompts our beta users wrote got dramatically shorter once we collapsed the surface. A 400-token instruction prompt dropped to 80 tokens because the LLM stopped needing to be talked through the orchestration. We saw similar tool-design lessons in the broader best MCP servers roundup.

#3. Docs that compile

Every code block in our docs runs in CI against a fresh sandbox tenant. The Claude Desktop config snippet, the Python mcp client example, the curl invocations, all of them. When the LinkedIn upstream changes a response shape, CI fails before a single user files a bug. Docs that compile are the cheapest customer-success investment I’ve ever made.

It also forced a discipline: if a doc snippet is too complex to test in CI, it’s too complex to ship to a developer who has 90 seconds of attention.

#What’s on the roadmap (without promising dates)

The honest answer to “what’s next” is: we are running with what we shipped while we listen. A few directions are clearer than others, and I’ll share them in the order of conviction rather than the order of urgency.

OAuth Device Flow for MCP clients. Sanctum tokens are workable but not lovable. Device Flow gets us closer to the auth experience developers expect in 2026.

Streaming responses for long-running tools. LaunchSequence can take 20-30 seconds when it warms up. MCP supports streaming in the spec; we don’t use it yet. Users notice the dead air.

Read-side breadth. A scoped SearchProspects tool that respects the audit and approval layers. We left this off the v1 surface for compliance reasons. We’re testing whether a strictly read-only, rate-limited search tool stays inside the policy envelope.

A real /docs/mcp site. Right now our reference lives in the dashboard and these blog posts. Standalone docs with versioned reference and a copy-paste cookbook is overdue.

Open metering. We have the Stripe usage-based metering scaffolding in the database. We haven’t exposed a per-call MCP tier because every conversation with developers said “just give me a flat plan.” That may change as workloads grow. We’ll telegraph well in advance if it does.

I will not commit to dates because dates in early-stage products are mostly fiction. What I will commit to is publishing what we learn whether the launch is a hit or a faceplant.

#FAQ

#How big is the MCP ecosystem as of 2026?

The MCP registry tracks well over 1,000 public servers as of Q2 2026, up from roughly 100 at the start of 2025 (Model Context Protocol, 2026). Adoption accelerated when Cursor, Windsurf, and Claude Code all shipped MCP support in the first half of 2025. The protocol itself is now the default integration layer between LLM hosts and external tools.

#Should I build my own LinkedIn MCP server or use Fintalio?

Build your own if LinkedIn is core IP for your product and you can absorb the operational cost of session management. Use Fintalio if LinkedIn is one of several integrations and you want a single Sanctum token plus a hosted OAuth bridge. The breakeven is roughly 3-4 engineer-months of operational overhead per year, before we count the cost of catching ToS drift. Most teams reach for an existing LinkedIn MCP server for that reason.

#What does “compliance-first” actually mean for a LinkedIn MCP?

It means three things: a hosted auth flow that never exposes session cookies to the agent, hard per-account daily action limits enforced before the write reaches LinkedIn, and write tools that land in an approval queue rather than firing immediately. The LinkedIn User Agreement explicitly prohibits unattended automation (LinkedIn User Agreement), so the approval gate is structural, not cosmetic.

#What’s the hardest part of running an MCP server in production?

Upstream drift. LinkedIn changes response shapes without notice, MCP host clients ship breaking version bumps, and Anthropic occasionally tightens the spec. We invested heavily in contract tests and version pinning. The 2026 MCP spec already had two minor revisions in its first year (modelcontextprotocol.io, 2026). Treat your MCP server like an API and run it like one.

#Where can I read more about Fintalio’s auth and rate-limit design?

The full architecture writeup lives in auth, rate limits, and audit logs for a LinkedIn MCP. That post goes through the Sanctum token model, the 120 req/min per-token throttle, the per-account daily limits, and the audit log schema we use to satisfy legal review.

#Closing thought

Building in public is uncomfortable. You publish the misses alongside the wins, and the misses age faster. But the LinkedIn-for-AI-agents category is small enough today that every honest retrospective from a shipping team is a public good. The next founder who tries this will move faster because of what we wrote down. That is the trade we’re making.

If you want to try Fintalio with Claude Desktop, the five-minute setup walkthrough is the fastest on-ramp. If you have questions, the comments are open and I read every one.

Ilyas Baba, Founder, Fintalio