Skip to main content
Discuss your build
Menu

Custom MCP Server Development

A production MCP server designed around what users need to do.

KNWN turns selected product capabilities into clear, authenticated MCP tools. We design the tool surface, connect your systems, preserve permissions, control write actions, test real tasks, deploy the server to your infrastructure, and hand over the complete implementation.

Discuss your build
One-off projectClient-owned code and infrastructureNo required KNWN hosting

For SaaS products, marketplaces, operational systems, and businesses with a stable source of truth.

The goal is not to expose more endpoints. It is to make the right work possible.

A model does not need your entire API. It needs a small set of tools whose names, descriptions, inputs, permissions, and results make the intended task obvious.

KNWN starts with the user request and works backward. We decide what the tool should accomplish, what information it needs, what the user is allowed to do, which system owns the result, and how the action should fail. Only then do we map it to your API or backend.

A generated wrapper can expose an endpoint. A useful MCP server exposes a job the user actually wants to complete.

From endpoint list to user workflow

A smaller tool surface is often the more capable product.

What an endpoint-first build might expose

  • GET /inventory
  • GET /inventory/{id}
  • GET /availability
  • POST /quotes
  • PATCH /quotes/{id}
  • Internal IDs and backend validation errors

What a workflow-first build might expose

find_available_options

Finds items that match the user's requirements and are available for the requested time and location.

create_quote_draft

Creates a reviewable draft using the selected items and customer details without committing the final transaction.

confirm_quote

Commits the approved quote only after the user has reviewed the summary and confirmed the action.

The workflow version gives the model fewer choices, gives the user clearer control, and gives your backend a cleaner boundary.

Connect real requests to live product capabilities.

Product and catalog discovery

Search and filter products, inventory, services, listings, documents, or account records using natural requests mapped to your actual data model.

Live checks

Retrieve availability, status, eligibility, pricing, schedules, balances, or other information that must come from the current source system.

Draft workflows

Prepare quotes, reservations, tickets, reports, orders, changes, or other work for review before anything is committed.

Authenticated account actions

Create or update records using the signed-in user's identity, permissions, and tenant context.

Approved transactions

Execute the final action only after the required summary, confirmation, validation, and policy checks have passed.

The work behind a reliable tool call

Every tool needs a clear job, a control boundary, and a test.

Workflow and tool surface

We identify the requests the server should handle, group related actions, remove overlap, and define when the model should and should not use each tool.

Inputs and structured results

We design inputs the model can populate reliably and results that remain useful in conversation, in logs, and in an optional interface.

Authentication and authorization

We connect the user's identity to the permissions enforced by your product. Authentication proves who the user is. Authorization still decides which data and actions that user may access.

Read and write boundaries

We classify tools as read, draft, or committed write actions and add confirmation, validation, idempotency, and recovery behavior where the risk requires it.

Failure and observability

We normalize upstream errors, make failures useful to the model, preserve operational detail in logs, and define what should be retried, corrected, or escalated.

Evaluations

We test direct requests, indirect requests, requests that should not trigger a tool, invalid inputs, permission failures, dependency failures, and complete workflow outcomes.

What a KNWN MCP build can include

  • Workflow and API audit
  • Tool map and action classification
  • Remote MCP server implementation
  • Input and output schemas
  • Authentication and authorization
  • Tenant and scope enforcement
  • Safe read, draft, and write behavior
  • Structured results and model-readable responses
  • Optional UI resources using the MCP Apps standard where useful
  • Rate-limit and error handling
  • Logging and audit events
  • Automated tests and evaluation fixtures
  • Deployment configuration
  • Runbook, documentation, and handover

The final list is defined around the approved workflow. We do not inflate the project by exposing tools nobody needs.

Your MCP server should remain your product infrastructure.

KNWN deploys to the client-controlled environment agreed in the scope. Your team receives the repository, infrastructure configuration, environment requirements, tests, evaluation scenarios, and operating documentation needed to own the implementation.

Key points

  • No required KNWN hosting
  • No mandatory Studio subscription
  • No hidden dependency on a KNWN dashboard
  • Optional support only when separately requested and scoped
Review security and handover

A strong MCP project starts with a real workflow and a reliable system behind it.

Good fit

  • A product or internal system already contains useful data or actions
  • The business can name the users and tasks the tools should support
  • An API, service layer, or controlled backend integration is available
  • Identity and permissions matter
  • The team wants to support one or more compatible AI clients
  • The final server must be testable, deployable, and owned by the client

Not enough on its own:

  • A list of endpoints with no prioritized user journey
  • A collection of documents that only needs question answering
  • A backend with no stable identity, validation, or source of truth
  • A request for unrestricted autonomous access to consequential actions

We quote the system you actually need, not a generic tool count.

Scope is shaped by:

  • Number and complexity of approved workflows
  • Quality and completeness of the upstream API
  • Read-only access versus state-changing actions
  • Authentication, scopes, roles, and tenant boundaries
  • Number of source systems involved
  • Need for optional interface resources
  • Evaluation and security depth
  • Target clients and deployment environment
  • Internal documentation and review requirements

Unless the proposal explicitly includes it, an MCP server engagement does not include:

  • Rebuilding an unstable or undocumented product API
  • Redesigning the client's underlying identity and permission model
  • A standalone web or mobile application
  • A general-purpose autonomous agent product
  • Formal compliance certification or third-party penetration testing
  • Unlimited revisions or indefinite maintenance
  • Guaranteed compatibility with untested clients
  • Guaranteed approval, ranking, or discovery by a third party

Frequently asked questions

How many tools should an MCP server have?

There is no universal correct number. The server should have the smallest set that can complete the approved workflows without forcing unrelated actions into one vague tool. We decide based on tool overlap, permissions, user intent, and evaluation results rather than a target count.

Can you build on top of our existing API?

Yes. That is often the fastest path when the API is stable and already enforces the right business rules. We audit it before scope, because gaps in authentication, validation, or write behavior may need to be resolved first.

Can the server support multiple customers or tenants?

Yes, when the product has a reliable tenant model. We map the authenticated identity and granted scopes into the tenant boundaries already enforced by your system, then test for cross-tenant access failures.

Will the server work in every MCP client?

Potentially, but MCP protocol compatibility does not guarantee feature parity. Transport, authentication, tool annotations, UI rendering, account policy, and host behavior can vary. Every target client included in scope is tested separately, and unsupported capabilities are documented rather than presented as portable.

Can you add an interface?

Yes, when a visual component makes the workflow easier to inspect, compare, edit, confirm, or navigate. The underlying tools should still return useful structured results so the workflow is not dependent on one interface.

Do you host the MCP server?

KNWN hosting is not required. The production server can be deployed to client-controlled infrastructure. Any development environment and the final deployment plan are defined in the scope.

What happens when the API fails?

We define how upstream errors are translated, which failures are safe to retry, what context the user needs, and what is recorded for operations. The evaluation suite includes representative dependency and partial-failure cases.

Bring us the workflow, not a list of endpoints.

Tell us what the user should be able to accomplish, which systems hold the data, and which actions need permission or confirmation. We will map the smallest production MCP surface that can do the job.

Discuss your build