We build custom Model Context Protocol servers so your team can query THEIR Holded, THEIR CRM, THEIR database, THEIR docs from Claude Desktop, Cursor or Zed, with no opaque SaaS, no black box, on your infra. Brand-new market, open window.
MCP with 5-10 tools/resources + local deployment + docs. More complex stack: custom quote.
Discovery → build → deployment → training. Fixed timelines, not open-ended.
@modelcontextprotocol/sdk + TypeScript. No weird frameworks, no lock-in.
These aren't hypotheticals, they're patterns we already have validated. If your case fits, we deliver it in 4 weeks. If it's something rarer, we assess it in discovery.
Your team stops having to log into Holded for basic lookups. Ask in Claude Desktop: 'top-billing customer this month', 'outstanding receivables for company X', 'marketing category expenses last 90 days'. The MCP server queries the Holded API in real time and answers with real data, not a summary, not an approximation. And it runs on your Holded plan with no extra fees.
Notion, Drive, Confluence, GitBook, Markdown repos. The MCP server indexes the content and exposes it as resources. Claude Desktop or Cursor can ask 'what does the onboarding manual say about process X' and it answers with exact citations to the source document, no hallucinations, no approximations.
Postgres, MySQL, BigQuery, Snowflake. The MCP server exposes pre-approved queries as tools (with guardrails: SELECT only, max LIMIT, no DROP/UPDATE/DELETE). Your product team can ask 'how many active users this week' without wrestling with SQL or waiting for the data team to reply.
HubSpot, Pipedrive, Salesforce, Zendesk, Intercom. A sales rep asks Claude 'which deals do I have closing this month' and gets the real list. Support asks 'tickets for customer X in the last 30 days' and sees them. Without opening the SaaS, without tool-specific training.
That internal system only your CTO understands, that legacy API from the ops team, that Python script that classifies invoices. We wrap it in an MCP server with a clean interface and your team uses it from Claude Desktop as if it were native. Especially useful when the team grows and documentation lags behind.
No proprietary frameworks. No black box. The resulting code is standard and any decent dev understands it without calling us in tears.
We use @modelcontextprotocol/sdk from Anthropic, the official SDK, not half-baked implementations. It supports stdio transport (local, for Claude Desktop / Cursor) and SSE/HTTP transport (remote, for access from distributed infrastructure).
Everything in its place. Actions that execute something → tools. Queryable data → resources. Parameterized prompt templates → prompts. Modeled badly, the LLM client never knows when to use what. Modeled well, it's a natural experience for the end user.
Input validation before touching your API. Rate limiting. Whitelist of operations (reads and writes are not the same). Full audit log of every call (who, what, when). Your data does NOT pass through our servers, the MCP runs on YOUR infra or the end client's.
Local (stdio, distributed via npm/binary) or remote (SSE on YOUR infra: Docker, VPS, AWS, GCP). Versioned on GitHub. Installation docs for non-technical users. Optional maintenance on a monthly fee when your underlying APIs change.
Claude Desktop (Mac/Windows), Cursor (all OSes), Zed, Continue, and whatever comes next. The spec is a standard, so a well-built MCP works with any client that implements it.
If your organization allows it, we publish the MCP as an open source repo under your brand. It gives you technical visibility and attracts talent. We can also keep it private on GitHub if you handle sensitive data. Your call.
We define what to expose: which tools (actions), which resources (data), which prompts (templates). We map your systems' endpoints. We identify the security guardrails needed. We come out with a signed spec before touching code.
Implementation with Anthropic's official MCP SDK. Unit tests on every tool. Integration tests against a sandbox of your real APIs. Usage documentation for end users (how to configure Claude Desktop, what they can ask).
Distributing the MCP to the teams (local via npm/binary, or remote on your infra). A 90-minute session with end users: how to invoke it, examples of useful questions, the system's limits. Internal documentation delivered.
Model Context Protocol is an open standard Anthropic published in 2024 so LLM assistants (Claude Desktop, Cursor, etc.) can connect to external tools and data in a uniform way. Before MCP, every integration was custom and every client implemented it its own way. With MCP, a well-built integration works in any compatible client. You should care because it means you can build the connection to your Holded (or your CRM, or your docs) ONCE and your whole team uses it from their preferred tool, Claude Desktop today, Cursor tomorrow, the next assistants after that.
Different levels. A chatbot/agent is an APPLICATION, it handles messages, does things, replies. An MCP server is INFRASTRUCTURE, it exposes capabilities from your systems that any LLM assistant can use. Chatbots often NEED MCPs underneath to access real data (without an MCP, the chatbot makes things up or asks the user to copy/paste). In practice, MCP is the right layer to integrate LLMs with YOUR stack. If you already have a chatbot, building MCPs underneath makes it far more useful.
The standard scope covers an MCP server with 5-10 tools/resources, local deployment (stdio for Claude Desktop / Cursor) and documentation. If you need remote deployment on infra (SSE on VPS/AWS/GCP), or connection to multiple systems requiring complex orchestration, we quote it custom. Optional monthly maintenance when your underlying APIs change, cost depends on the expected volume of change. A concrete figure after 30 min of discovery based on your case.
MCP is from Anthropic but the spec is open. As of today (mid-2026) the clients that support it natively are those in the Anthropic ecosystem + dev tools (Claude Desktop, Cursor, Zed, Continue, Goose). ChatGPT and Gemini have their own plugin/tool systems that are NOT MCP. If you need the same backend working across multiple LLMs, we can design the core logic and expose it as an MCP server + specific adapters for other systems (higher ticket, evaluated case by case).
Not by default. The MCP server runs on YOUR infra (or locally on team machines in stdio mode). When the user queries from Claude Desktop, the flow is: local client → local MCP → your API → local MCP → local client → Claude's API to process the response. Your data goes to Anthropic ONLY if the LLM client includes it in the prompt to reason over it, but it is NOT stored at Anthropic for training (the consumer API has that policy). For highly sensitive cases (healthcare, legal, financial), we evaluate deployment with an on-premise LLM (Llama 3 / Qwen / etc.) instead of Claude, the MCP server is the same, only the client changes.
MCP is an open spec, not a closed product. Even if Anthropic stopped pushing it tomorrow, the code we write is standard TypeScript with an open source SDK. If the standard evolves (version 2.0 with changes), the cost of updating is proportional to the change. But MCP in its current form already has real momentum: Cursor, Zed, Continue and Goose support it, and it's growing, I don't see a realistic scenario where it disappears within 18 months. At 5 years, up for review.
It depends on how it's accessed. If your system is web-based (HTML interface) we can scrape it but it's fragile, we don't recommend it for production. If it's a legacy desktop app with nothing exposed, there you first need to build an API layer (a separate project). If what you have is a direct database, then yes, an MCP server against Postgres/MySQL is perfectly viable and very useful.
Related: AI chatbots over your business · Guide to the Holded API v2
30 minutes of discovery. We tell you whether your case fits one of the 5 patterns or is custom, what it costs and how long it takes.
