Integration audit and design
We map the systems your assistant needs, which operations are read versus write, and where the risk sits. You get a server design before any code is written.
005Model Context Protocol (MCP)
MCP servers that connect AI assistants to your systems
The Model Context Protocol (MCP) is the open standard that lets AI assistants like Claude read your data and act inside your tools. We design and build custom MCP servers that expose your databases, APIs, and internal workflows to LLMs with the access controls your security team expects. For CTOs and product leaders who want AI working against real company context, not generic answers.
AI005
What we build
What an MCP engagement includes
A production MCP server is more than a wrapper around your API. We cover the full path from integration design to deployment and monitoring.
Custom MCP server development
We build servers that expose your data sources and internal APIs as MCP tools and resources, with schemas an LLM can actually use reliably.
Authentication and access control
OAuth flows, per-user permissions, and scoped tokens so the assistant only sees what the person driving it is allowed to see.
Tool design for reliability
Tool naming, descriptions, and response shaping tuned so the model picks the right operation and handles errors sanely. This is where most MCP projects quietly fail.
Deployment and hosting
Local servers for desktop use or remote servers behind your infrastructure, containerized and wired into your existing CI/CD and logging.
Testing and evaluation
Automated test suites that exercise every tool, plus evaluation runs that measure how well the model uses the server on realistic tasks before your team depends on it.
How we work
From use case to running server
(4)- 1
Scope the use case
We start with what your users or employees actually need the assistant to do, then work backward to the minimum set of tools and data sources required.
- 2
Design the tool surface
We specify each tool, its inputs, its outputs, and its failure modes, and review the design with your engineers before implementation.
- 3
Build and test
We implement the server, wire authentication, and run it against real prompts and edge cases until tool selection and error handling hold up.
- 4
Deploy and hand over
We ship the server into your environment, document how to extend it, and train your team so adding the next tool does not require calling us back.
Why Webisoft
Why teams hire us for MCP work
MCP is young, and most of the hard lessons are not written down yet. We have been building LLM integrations since before the protocol existed.
Applied AI engineering, not demos
We build AI systems that run in production, with the logging, permissions, and failure handling that separates a prototype from something your company relies on.
Security first
MCP servers touch real company data. We treat access scoping, prompt injection exposure, and audit trails as core requirements, not afterthoughts.
Full-cycle team
Backend engineers, infrastructure, and AI specialists under one roof, so the same team that designs the server also deploys and hardens it.
Built to be maintained
You get clean code, documentation, and a handover your own developers can extend. No black boxes, no dependency on us to change a tool description.
FAQ
MCP questions we hear most
(4)- MCP is an open standard, introduced by Anthropic, for connecting AI assistants to external data sources and tools. Instead of building a custom integration for every assistant and every system, a team builds one MCP server and any MCP-compatible client can use it. This turns integrations into reusable infrastructure rather than one-off connectors, and the standard has been adopted across a growing set of AI clients and development tools.
- Public MCP servers already exist for common products such as GitHub and Postgres, and adopting them is usually the fastest path for those systems. A custom server becomes necessary when the value sits in internal systems, proprietary data, or workflows specific to the business, since no off-the-shelf server will expose those. Most organizations end up with a mix, adopting public servers where they fit and building custom ones for what makes them different.
- Standard practice is to scope every tool to the permissions of the authenticated user, require confirmation for write operations, and log all tool calls for audit. Prompt injection is a specific risk to review, because an MCP server that returns untrusted content, such as text from documents or the web, can be used to manipulate the model into unintended actions. Treating server outputs as untrusted input and limiting what tools can do are the core mitigations.
- It depends on how many systems the server touches and the state of their APIs. A focused server for one or two well-documented systems is typically a matter of weeks, while a broader integration layer across legacy systems with poor APIs takes longer. Scoping the systems, tools, and permission model first is the reliable way to get a real estimate before committing to a build.
MCP Capabilities
Where We Add Value on MCP Projects
An MCP server is only useful if it exposes the right data, enforces the right permissions, and stays reliable when a model calls it thousands of times a day. These are the areas where our engineering work pays for itself.
Custom MCP Servers
We build MCP servers in TypeScript or Python using the official SDKs, exposing your internal systems as tools, resources, and prompts. Each tool gets a precise JSON schema and a description written for the model, not for humans, because vague tool definitions are the most common reason agents pick the wrong tool or pass bad arguments.Enterprise System Connectors
We connect MCP servers to the systems your teams already run: Postgres and Snowflake, Salesforce, SAP, Jira, SharePoint, and internal REST or GraphQL APIs. The server layer handles pagination, rate limits, and retries so the model receives clean, bounded results instead of raw API dumps that blow out the context window.Auth and Permission Mapping
MCP calls run with the identity of a real user, so we implement OAuth 2.1 flows and map your existing roles into per-tool and per-row permissions. A sales rep querying through Claude sees only their accounts, and destructive tools can require an explicit confirmation step before they execute.Context Shaping and Filtering
Returning a 400 row table to a model wastes tokens and degrades answers. We design each tool response to return summarized, ranked, or truncated data with references the model can follow up on, which keeps conversations cheap and makes multi-step reasoning noticeably more accurate.Transport and Deployment
We deploy servers over stdio for local desktop use or streamable HTTP for shared remote access, containerized and running in your cloud account. Remote servers get standard operational treatment: health checks, structured logging, horizontal scaling, and versioned releases so a schema change never silently breaks running clients.Evaluation and Observability
Before launch we build an evaluation set of realistic tasks and measure whether the model selects the correct tools and produces correct outcomes. In production, every tool call is logged with arguments, latency, and result status, which gives you an audit trail and a concrete way to find and fix failing workflows.
Our Approach
How an MCP Engagement Runs
(4)- 1
Workflow and Data Audit
We start by mapping the workflows you want models to perform and the systems that hold the required data. The output is a scoped tool inventory: which tools to expose, what each returns, what permissions apply, and which workflows are out of scope for the first release. - 2
Server Design and Prototype
We define tool schemas, resource URIs, and the auth model, then ship a working prototype against a staging copy of your data within the first weeks. You test it directly in Claude Desktop or your own client, which surfaces naming and scoping problems long before production hardening. - 3
Hardening and Integration
We add OAuth, rate limiting, input validation, secrets management, and audit logging, then run the evaluation suite against real tasks. This phase also covers deployment into your infrastructure, whether that is ECS, Kubernetes, or a managed platform, with CI pipelines and rollback in place. - 4
Rollout and Iteration
We launch to a pilot group, review tool call logs weekly, and adjust tool descriptions and response shapes based on where the model actually struggles. Most servers need two or three iteration cycles before tool selection is reliable, and we plan for that instead of declaring victory at deploy.
FAQ
Questions Buyers Ask About MCP Work
(6)- The two biggest drivers are the number of systems being connected and the complexity of the permission model. A read-only server over one clean API is a matter of weeks. A server that spans several legacy systems, needs per-user OAuth, and includes write actions with approval steps takes longer because most of the effort goes into auth mapping, data shaping, and testing rather than the protocol itself. We scope a fixed first release so you see working software early instead of paying for a long design phase.
- Local stdio servers are fine for individual developers, but for an organization we almost always recommend a remote server over streamable HTTP. A remote server gives you central authentication, one place to patch and upgrade, usage logging for compliance, and no dependency on what is installed on each laptop. The trade-off is that you now operate a service, so it needs the same uptime and security treatment as any internal API.
- Permissions are enforced in the server, never in the prompt. Each request carries the user's identity through OAuth, and the server applies your existing role and row-level rules before any data reaches the model, so the model physically cannot retrieve what the user cannot access. We also scope tokens narrowly, log every call with the acting identity, and put confirmation gates on any tool that writes or deletes.
- MCP is an open standard, so one server works with Claude, Claude Code, and the growing set of clients and frameworks that speak the protocol, including OpenAI Agents SDK based agents and many IDE tools. That portability is the main argument for MCP over building one-off function calling integrations per vendor. We test against the clients your teams actually use and keep the server free of client-specific assumptions.
- Tools can write: create a ticket, update a CRM record, trigger a deployment. The real question is how much autonomy you grant. Our default pattern is read tools run freely, low-risk writes run with logging, and high-risk writes require human confirmation inside the conversation. We define that risk tiering with you during the audit phase so the rules reflect your compliance requirements rather than a generic template.
- Start with one workflow where employees currently copy data by hand into a chat model, because that is where an MCP server shows value fastest. We run a short scoping exercise, usually one to two weeks, that produces the tool inventory, an architecture recommendation, and a cost estimate for the first release. If the audit shows a simpler integration would serve you better, we tell you that instead of building a server you do not need.
