DEV Community: iTech Soft Solutions

Building MCP Servers in 2026: What Changed and What Production Needs

iTech Soft Solutions — Mon, 02 Nov 2026 03:00:00 +0000

This is a condensed version of our full MCP Development Guide 2026, which includes working TypeScript and Python servers, the full OAuth flow and a security checklist.

If you learned the Model Context Protocol from a 2025 tutorial, parts of it no longer apply. The 2026-07-28 specification made MCP stateless, and that changes how you design, scale and secure a server.

We build and run the hosted MCP server for Feedlio, our social media SaaS, which is listed on the official MCP Registry, Smithery and mcpservers.org. These are the points that mattered most in production.

What changed in 2026-07-28

No initialize handshake. Every request carries its protocol version and client capabilities in _meta. Servers implement server/discover to advertise what they support.
No protocol sessions. The Mcp-Session-Id header is gone. If you need state across calls, return an explicit handle the model passes back as a normal tool argument.
Servers no longer send requests to clients. Elicitation now uses Multi Round-Trip Requests: the server returns resultType: "input_required", and the client retries with the input.
Deprecated: roots, sampling, logging, the old HTTP+SSE transport, and Dynamic Client Registration (in favour of Client ID Metadata Documents). There is now a minimum twelve-month deprecation window.

Tools, resources and prompts work as before, so most tool code carries over. The big win: any instance behind a load balancer can answer any request.

Pick the transport

stdio for local tools (files, local databases, CLIs). The server runs with the user's privileges and reads credentials from the environment.
Streamable HTTP for anything shared or SaaS. One endpoint, one POST per message, and each POST carries MCP-Protocol-Version, Mcp-Method and (for tool calls) Mcp-Name headers, so gateways can route and rate-limit without parsing JSON. Validate the Origin header to block DNS rebinding.
HTTP+SSE is deprecated. Don't start new work on it.

Design tools around intent, not endpoints

The most common mistake is mirroring a REST API one endpoint at a time. A model that has to chain get_customer, get_customer_accounts and get_account_invoices makes more mistakes and spends more tokens than one that calls find_overdue_invoices(customer, min_days_overdue).

One tool per user intent, no overlapping tools.
Separate reads from writes and mark them with readOnlyHint / destructiveHint (hints for hosts, not security controls).
Descriptions are prompts: say when to use the tool, give formats and units ("ISO 8601 UTC, e.g. 2026-11-02T09:00:00Z"), and say where IDs come from ("accountId comes from list_social_accounts").
Use enums and limits in the schema, not in prose.

Errors the model can act on

MCP has two error channels. Protocol errors (malformed requests, unknown tools) are hard for a model to recover from. Tool execution errors are normal results with isError: true, and clients pass them back to the model so it can self-correct.

So write the error for the model:

"404" gives it nothing.
"No post with id p_99. Call list_posts to find valid ids." gives it a next step.

Never return stack traces, hostnames or secrets: anything you return can end up in the chat.

Make writes idempotent

Models retry, and under the stateless Streamable HTTP transport a broken stream loses the in-flight request, so the client re-issues it. Without idempotency, a retry creates a duplicate. Accept an idempotency key, store it with the result, and return the original result when the key repeats:

const postId = `post_${idempotencyKey}`;
if (!posts.has(postId)) posts.set(postId, { text, publishAt, status: 'scheduled' });
return { content: [{ type: 'text', text: JSON.stringify({ postId, status: 'scheduled' }) }] };

Authorization for remote servers

Your MCP server is an OAuth 2.1 resource server. The client gets a token from your authorization server (often your existing identity provider) using PKCE and a resource parameter, after discovering it through your Protected Resource Metadata at /.well-known/oauth-protected-resource.

Two rules prevent most serious mistakes:

Validate the audience. Accept only tokens issued for your server.
Never pass tokens through. When your server calls a downstream API, it uses its own credentials. Token passthrough is explicitly forbidden: it breaks audit trails and creates confused-deputy risks.

Design scopes around what a user would approve (posts:read must not publish), and use 403 insufficient_scope for step-up instead of wildcard scopes.

Security you have to plan for

Prompt injection through tool results. A customer email or social comment can say "ignore previous instructions". Return only the fields needed, never let a read result unlock a write, and require approval for side effects.
Tool poisoning. Descriptions from untrusted servers are untrusted. Allowlist servers, pin versions, alert on description changes.
Least privilege. Minimal scopes, per-user tool lists, tenant filtering in the data layer, not in instructions to the model.
SSRF. If a tool fetches a model-supplied URL, enforce HTTPS, block private ranges, set size and time limits.

Three lessons from running the Feedlio MCP server

Platform requirements must be in the schema. TikTok needs privacy settings and a music-usage confirmation, YouTube a title and a category. If the schema has no field for it, the model can't send it, however capable it is.
Media arrives as a public URL. add_media_from_url fetches the file server side. Pushing binaries through tool arguments is expensive in context and fragile.
A person approves before anything goes live. The assistant prepares the post; a human confirms it before it's scheduled. Where you can, enforce approval in your product, so it works the same whichever client is connected.

Test it

Use the MCP Inspector (Node 22.19+):

npx @modelcontextprotocol/inspector --server-url http://127.0.0.1:3000/mcp --transport http

Then test with the assistants your users actually run, and add adversarial tests that plant instructions in returned data.

Read the full guide

The full guide covers the architecture, a complete TypeScript (v2 SDK) and Python server, the OAuth flow step by step, a threats-and-controls table mapped to the OWASP LLM Top 10, operations, and realistic timelines from a 1–2 week prototype to an 8–14 week public SaaS server.

👉 Read the full MCP Development Guide 2026

iTech Soft Solutions builds AI agents, LLM integrations and MCP servers: AI development services.

Liquidity Provider Integration for Crypto Exchanges: REST, WebSocket, FIX and Smart Order Routing

iTech Soft Solutions — Fri, 30 Oct 2026 03:00:01 +0000

This is a condensed version of our full guide, How to Integrate a Liquidity Provider in a Crypto Exchange, which also covers provider profiles, costs and compliance.

A new exchange can have a fast matching engine, a clean UI and solid wallets, and still lose users in its first week. The reason is usually liquidity: empty order books, high slippage and wide bid-ask spreads. Traders try a market order once, get a bad fill, and leave.

Liquidity provider integration fixes that by connecting your exchange to outside depth. It sounds like a business deal. In practice it is an integration project with real engineering risk, and most of the mistakes we see are architectural.

Where liquidity comes from

Most exchanges combine several sources:

Centralized exchanges: depth from large venues, reached over their APIs.
Market makers: professional firms that quote both sides of the book.
Liquidity aggregators: services that combine several sources behind one connection.
Decentralized pools: on-chain liquidity, relevant for hybrid designs.

One provider or several?

Starting with one provider is cheaper and simpler. It is also a single point of failure: when that provider lags or goes down, your books go thin.

Feature	Single provider	Multiple providers
Initial setup cost	Lower	Higher
Implementation complexity	Low	Medium
Market depth	Limited	High
Reliability	Medium	High
Redundancy	Weak	Strong
Slippage	Higher	Lower
Scalability	Limited	Excellent

Our advice: even if you launch with one provider, design for several from day one. Adding a second provider to an architecture built for one is a rewrite, not a config change.

The architecture: five components

Provider connectors keep secure links to each source over REST, WebSocket or FIX.
Market data engine handles live bid/ask prices and order book depth.
Liquidity engine is the core: it merges order books and ranks sources.
Order book engine combines every provider's liquidity into one consolidated book your users see.
Smart order routing (SOR) picks the best venue, or the best split across venues, for each execution.

Keep these as separate services or at least separate modules. When a provider changes its API, only its connector should change.

Choosing the protocol for each job

You will usually use all three:

REST for authentication, account configuration and other request/response work.
WebSocket for live order books and trades. Polling REST for market data is too slow and too expensive.
FIX for low-latency institutional order flow, where the provider supports it.

Whatever the protocol, encrypt API keys, whitelist IPs, give credentials the least privilege they need (read-only where possible), rotate keys, store secrets in a dedicated secrets manager, and log every access.

The 12 steps, grouped into five phases

Plan

Define your business model. Spot, margin, futures or multi-asset: each needs different depth.
Select providers on depth, API reliability, asset coverage, fill quality and regulatory fit.

Connect

Establish secure API connectivity using the REST/WebSocket/FIX split above.
Build a market data layer that ingests, validates, processes and distributes feeds with low latency.
Normalize provider data. Symbols, order types and precision rules differ by provider. Map them to one internal standard before anything else touches them.

Engine

Implement the liquidity engine that consolidates books and manages providers.
Build smart order routing that routes by price, depth, execution cost and latency.

Protect

Integrate risk controls: exposure limits, position tracking, slippage protection and circuit breakers that pause trading during flash crashes or extreme volatility.
Implement failover: automatic switch to backup providers, redundant market data feeds and duplicated infrastructure.

Prove and run

Performance test latency, load, routing logic, failover behaviour and security before launch.
Deploy monitoring for provider uptime, API speed, feed health and execution quality.
Scale: add providers, introduce aggregation and expand trading pairs as volume grows.

Normalization deserves its own layer

Step 5 is where many integrations quietly break. One provider calls a market BTCUSDT, another BTC-USDT, a third XBT/USDT, with different tick sizes and minimum quantities. A minimal illustration of the idea:

SYMBOL_MAP = {
    "provider_a": {"BTCUSDT": "BTC/USDT"},
    "provider_b": {"BTC-USDT": "BTC/USDT"},
    "provider_c": {"XBT/USDT": "BTC/USDT"},
}

def normalize(provider: str, raw_symbol: str) -> str:
    try:
        return SYMBOL_MAP[provider][raw_symbol]
    except KeyError:
        # Unknown symbols never reach the engine
        raise ValueError(f"Unmapped symbol {raw_symbol} from {provider}")

In production the map also carries precision, lot size and order-type rules, and it lives in configuration, not code. The principle is the same: unknown data is rejected at the edge instead of producing a symbol mismatch or a wrong trade downstream.

Smart order routing and risk controls work together

Smart order routing decides where each order goes. For a small order that is usually the venue with the best price and enough depth. For a large order, SOR splits it across sources to improve the average execution price instead of walking one provider's book. Routing should weigh price, available depth, execution cost and latency together; the cheapest quote on a slow or thin venue is often the worst fill.

Routing alone is not safe. Put the risk layer in the same execution path:

Exposure limits per provider and per asset, so one venue's failure can't take down your book.
Position tracking in real time, reconciled against provider fills.
Slippage protection that rejects or re-routes orders whose expected fill drifts past a threshold.
Circuit breakers that pause trading on a pair during flash crashes or extreme volatility.

A pre-launch test list

Before real users trade, run each of these deliberately:

Kill one provider's connection mid-session and confirm failover happens without manual action.
Replay a burst of market data and measure end-to-end latency to the consolidated book.
Send orders large enough to force a split and check the average fill against a single-venue fill.
Feed an unmapped symbol and confirm it is rejected at the normalization layer.
Trip a circuit breaker on a test pair and confirm trading resumes cleanly.

Mistakes we see most often

Depending on one provider, with no failover plan.
Skipping smart order routing, which means higher slippage and weaker fills.
Weak normalization, which causes symbol mismatches and trading errors.
Ignoring latency and order book synchronization.
Underestimating monitoring. Crypto markets run 24/7, so your liquidity stack has to as well.
Designing for today's volume instead of next year's.

How long it takes

From the guide's FAQ: a simple integration takes about 2–4 weeks; a multi-provider architecture with aggregation and routing takes 8–12+ weeks. Testing and failover work are the parts teams tend to cut, and the parts they regret cutting.

Read the full guide

The full version covers how to compare the major liquidity providers, cost ranges by integration tier, KYC/AML obligations and a build-vs-buy section: Read the full guide.

iTech Soft Solutions has built AI and blockchain products since 2016, including exchange platforms. If you're planning an exchange, see our crypto exchange development work.

How to Evaluate White-Label Crypto Exchange Software: A Buyer's Checklist

iTech Soft Solutions — Fri, 23 Oct 2026 03:00:07 +0000

This is a condensed version of our full guide, White-Label Crypto Exchange Software in 2026: The Complete Buyer's Guide, which also covers licensing by region, total cost of ownership, the launch timeline and post-launch operations.

Most exchanges that fail do not fail because of the code. They fail because the founder bought the wrong kind of software for the business, signed with a vendor who disappeared after the final invoice, launched into an empty order book, or found out six months in that the licence demanded controls the platform could not produce. All four are visible before you sign. This is the checklist we use to see them.

"White-label" means three different purchases

The same label is attached to three products with different risk, cost and ceiling:

Hosted SaaS. The vendor runs the platform. You get an admin login and a branded front end for a monthly fee or revenue share. No source code, no say in where servers live or who has access. Your customer data, hot wallet keys and uptime belong to a third party. When a regulator asks who holds the keys, the answer is "our vendor".
Licensed source code. You buy a licence, receive the code, deploy it on infrastructure you control and can modify it or hire anyone to modify it. You own hosting, patching, key management and monitoring; in return you own the platform. For any business that intends to be licensed, this is usually the only defensible model.
Custom build. Designed for your business model. Right for institutional venues, novel market structures and unusual regulatory constraints. Wrong for most first-time founders: slower, more expensive, and it delays the moment you learn whether customers want the product.

The outcomes we see work best are hybrid: license a proven core (matching engine, wallet services, ledger, admin console) with source code, then customize the layers where you actually compete: onboarding, local payment rails, product mix, brand.

Two things to settle before you talk to a vendor

Software vendors cannot sell you a licence or liquidity, and both take longer than the software.

A licence plan. Do you have, or are you actively obtaining, authorisation in your target market? If not, pause the vendor search.
A liquidity plan. Named market makers or a budget for them. If the software budget is the whole budget, the business will not survive launch regardless of which vendor you pick.

The module checklist (what to probe, not what to tick)

Every demo looks good. The question is whether each module is deep enough to run a business or only deep enough to survive 30 minutes.

Matching engine. Determinism: the same order sequence must always produce the same trades. Ask how the engine recovers after a crash and whether it replays from a journal. Order types: limit, market, stop-limit, post-only at minimum. Self-trade prevention, or your own market makers will cross themselves and inflate volume. Atomic ledger updates: ask what happens if the database write fails halfway through a match. Do not chase headline throughput; a regional exchange needs a correct, recoverable engine more than an extreme one.

Wallets. Which chains and token standards are native, and how a new one is added. Own nodes or third-party RPC, and whether you can switch. How reorganisations and stuck transactions are handled. Whether deposit and withdrawal flows can plug into an external custody provider or MPC wallet.

KYC, AML, monitoring. Tiered KYC with configurable limits. Integration points for third-party identity and blockchain analytics providers. Sanctions and PEP screening at onboarding and ongoing. Travel Rule message handling. Audit logs that show who approved what, when.

Admin console. Role-based access with granular permissions. Maker-checker approvals for manual balance adjustments and large withdrawals. Fee and market configuration without code changes. Exportable reports for finance and compliance. The admin console decides how many staff you need.

Market maker API. REST and WebSocket with documentation, rate limits and API key permissions. Market makers benchmark your API before they commit capital.

Day-one requirements: spot engine, custodial wallets, KYC/AML, admin console with maker-checker, market maker API. Usually day one: fiat on-ramp, mobile apps. Later: P2P (unless banking access is limited in your market), futures and margin (only after licensing and risk controls), staking, launchpad, copy trading.

Custody: where exchanges actually fail

Chainalysis counted over $3.4 billion stolen from January through early December 2025, with the Bybit compromise alone at $1.5 billion. The attack patterns they describe are attacks on private key infrastructure and signing processes that route around cold wallet controls, exploitation of third-party wallet integrations, social engineering of legitimate signers, and IT workers embedded inside crypto companies. "We use cold storage" is no longer a sufficient answer. The attack surface includes the signing workflow, the people who approve, the vendors whose tools touch the signing path, and the hiring process.

What to require:

Three wallet tiers. Hot wallets sized from historical withdrawal data plus a buffer; warm wallets refilling hot under policy limits and human approval above thresholds; cold storage holding the large majority of assets with multi-party approval for any movement. The ratio is a risk-team decision, not a config default.
MPC, multisig or HSM, chosen deliberately. None of them stops a signer approving what a spoofed screen shows them. Whatever you choose, signers must independently verify transaction details and policies must be enforced by the system, not by trust.
Withdrawal controls demonstrated live: per-user, per-asset and global limits that can change quickly in an incident; address allowlisting with a time delay; velocity rules that hold a full-balance withdrawal shortly after a 2FA change; maker-checker above thresholds on separate devices; an emergency stop per chain or global that does not take trading offline; continuous ledger-to-chain reconciliation with alerts.
Application security against a public yardstick. Ask which OWASP ASVS requirements the vendor tests against and for recent penetration test summaries. Secrets never in source code, isolated admin networks, tamper-proof centralized logging.
People and access. Verify the identity of engineers who receive production access. No standing access to keys or databases; just-in-time, logged. Separate the people who deploy code from the people who approve withdrawals. Ask who at the vendor will have access to your production after launch and how it is revoked.

Liquidity is a commercial relationship, not a feature

A trader who sees a wide spread and thin depth on BTC/USDT leaves and rarely returns. Thin books are also easy to manipulate, which makes liquidity a security and compliance concern.

A launch sequence that works: launch with five deep markets rather than fifty empty ones; bridge or market-make the majors so headline pairs are competitive on day one; add local fiat pairs where your payment rails give a real edge; list long-tail assets only with a committed market maker; publish fees and maker incentives so providers can model returns.

Market maker contracts need measurable obligations: maximum spread, minimum depth at defined levels, uptime. Their activity must be visible to compliance with self-trade prevention on.

A vendor who offers "trading bots" to make your charts look busy is offering wash trading. It is the fastest way to lose a licence, a banking relationship or an aggregator listing.

Seven demo requests that break the script

Place an order, then restart the matching engine. Show the book and balances intact.
Withdraw to a newly added address. Show the delay and the approval flow.
Adjust a user's balance manually. Show who approved it and the audit log.
Pause withdrawals on one chain only while trading continues.
Show a deposit that was reorganised out of the chain and how the ledger corrected it.
Export last month's trades and balances in a format an auditor could use.
Create an admin role that can view users but change nothing.

A production-grade platform handles these calmly. A demo changes the subject.

The scoring matrix

Criterion	Weight	Strong answer
Security and custody	25%	Layered wallets, enforced withdrawal policies, recent independent testing
Source code and IP terms	20%	Full code, clear licence, no obfuscation, escrow or equivalent
Production track record	20%	Named, verifiable live deployments with long operating history
Support and updates	15%	Regular releases, defined support terms, responsive engineers
Compliance readiness	10%	KYC, AML, Travel Rule and reporting integrations in place
Total cost of ownership	10%	Transparent pricing, no hidden revenue share

Price is 10%. A cheaper platform that leaks funds or stalls your licence is the most expensive option available.

Red flags that end the conversation

"Turnkey exchange business" promises of users or income. Nulled or pirated scripts (a common backdoor delivery mechanism, with no updates and no legal right to run them). No update history: ask for the changelog and check the dates. Encrypted or licence-server-locked code the vendor can switch off. Bundled volume bots. References you cannot verify: ask for a live, named deployment and, ideally, a conversation with its operator.

Timeline reality

For a standard spot exchange with modest customisation, expect roughly two to four months to soft launch: discovery (1–2 weeks), infrastructure (1–2, overlapping), branding and customisation (3–8), integrations (2–6, overlapping), security testing and remediation (2–4), soft launch with reduced limits (2–4). Licensing runs in parallel and is usually the critical path.

Read the full guide: White-Label Crypto Exchange Software in 2026: The Complete Buyer's Guide covers licensing in the EU, UAE, Singapore, Malaysia and the US, the FATF Travel Rule, a full cost-of-ownership model, the go-live checklist and post-launch operations.

iTech Soft Solutions has built exchange and blockchain systems since 2016; our TradiumPro platform runs live exchanges including CryptoWag and Xoibit. See our crypto exchange development services.

11 Prompt Engineering Practices That Survive Production

iTech Soft Solutions — Wed, 21 Oct 2026 01:35:24 +0000

This is a condensed version of our full guide. The original, with diagrams, evaluation methods and a section on enterprise prompt architecture, is on our blog: Prompt Engineering Guide 2026.

Most prompt advice is written for chat: how to get a nicer answer from a chatbot once. Production is different. A prompt in a product runs thousands of times a day, on inputs nobody has seen, and its output is often parsed by code rather than read by a person. A clever one-off trick does not survive that. A disciplined habit does.

These are the eleven practices that most reliably separate production-grade prompting from trial and error in the systems we build. None of them depend on a particular model or provider.

1. Be specific and unambiguous

Vague instructions produce vague results. "Summarise this ticket" leaves the model to guess the length, audience and focus. "Summarise this support ticket in two sentences for an on-call engineer: what broke and what the customer already tried" does not. Precision in the prompt is the cheapest quality improvement available.

2. Show, don't just tell

When behaviour matters, a few well-chosen examples usually beat a paragraph of description. Examples demonstrate the pattern, including edge cases, more efficiently than prose. Pick examples that cover the cases the model gets wrong, not three versions of the easy case.

3. Give the model the context it needs, and no more

Supply the relevant background, but resist dumping everything you have into the context window. Curated context is faster, cheaper and more accurate than an overstuffed window. In retrieval systems this is the difference between "top 3 relevant passages" and "the whole knowledge base, just in case".

4. Specify the output format explicitly

If software will consume the output, define the exact shape: a JSON schema, field names, allowed values, what to return when a field is unknown. Use your provider's structured-output or tool-calling features where they exist, and validate the result anyway.

5. Separate instructions from data

Keep your instructions and the user-supplied content in clearly marked sections, for example with XML-style tags. The model then knows what to follow and what to process. This one habit prevents a whole class of bugs, and it is the first line of defence against prompt injection (see #10).

6. Start simple, add complexity only when measured

Begin with the simplest prompt that could work. Add chain-of-thought, more examples or extra rules only when an evaluation shows they help. Every added instruction is something else that can conflict, cost tokens and break when the model changes.

7. Tell the model what to do when it is unsure

Models fill gaps confidently unless you give them a way out. Say what to do when information is missing: return null, ask a clarifying question, or answer "not in the provided documents". A permitted "I don't know" is far cheaper than a confident wrong answer in production.

8. Version and store prompts as code

Prompts are part of your application. Keep them in version control, review changes like code, and record which prompt version produced which output. When quality drops after a release, you need to know what changed.

9. Evaluate before and after shipping

Build a small, representative test set of real inputs with known good outputs, and run it on every prompt or model change. Score what matters to your product: correctness, format validity, refusal behaviour, length. After launch, sample live traffic and keep adding failures to the test set. Without this, every change is a guess.

10. Treat all model inputs as untrusted

Anything that enters the context from outside, such as user messages, retrieved documents, web pages, emails or tool results, can contain instructions aimed at the model. Defend in depth: separate instructions from data, give tools the least privilege they need, require human approval for irreversible actions, and validate outputs before acting on them. The OWASP Top 10 for LLM Applications puts prompt injection first for a reason.

11. Iterate: good prompts are refined, not written once

The first version of a prompt is a hypothesis. Look at real failures, change one thing, re-run the evaluation, and keep what measurably helps. Teams that treat prompts as living code end up with prompts that are shorter, clearer and more reliable than the first draft.

The mistakes we see most often

Vague, underspecified prompts that leave the model to guess.
Overloading the prompt with every rule anyone ever thought of.
Confusing instructions with data, so user content gets obeyed instead of processed.
Assuming a persona grants expertise. "You are a senior lawyer" does not add legal knowledge the model lacks.
Shipping without evaluation.
Treating prompts as disposable strings scattered through the codebase.
Trusting output blindly instead of validating it.

Where this fits

Prompt engineering is now one layer of a larger discipline sometimes called context engineering: deciding what goes into the model's context, from instructions and examples to retrieved documents, tool results and memory. The habits above carry over directly to retrieval-augmented generation and to AI agents, where a bad prompt does not just produce a bad answer but a bad action.

The full guide covers each of these in depth, including zero-shot vs few-shot vs chain-of-thought, structured output, tool calling, RAG and agent prompts, context windows, evaluation methods and enterprise prompt architecture.

Read the full guide: Prompt Engineering Guide 2026: Enterprise Prompt Design Best Practices

We're iTech Soft Solutions, an AI and blockchain engineering team that has been building since 2016. If you're putting an LLM feature into production, our LLM integration team can help.