DEV Community: Vlastimil Elias

Domain Knowledge for AI agents: static vs just-in-time teaching

Vlastimil Elias — Tue, 20 Oct 2026 13:18:41 +0000

MCP connects agents to tools and data. That is only half of Agent Experience. The other half is agent teaching: how the agent should interpret tool results, what to ask user next, and when not to invent an answer from general knowledge.

What you are teaching is Domain Knowledge — the curated rules raw APIs and databases do not carry safely on their own (funnels, status meanings, what must not be mixed up). Without it, agents misread codes and invent incorrect next steps. Getting that knowledge into the agent at the right moment is a classic Knowledge Engineering problem: capture how experts reason about the domain, then deliver it through channels the runtime actually honors — not only as a wiki page nobody loads.

Early LLMs were mostly knowledge recall machines — answer from what was stored in the weights. Modern models are intentionally trained and productized toward agentic behavior: plan tool calls, read each result, decide the next hop, and ask the user when something is missing (the tool-use / agentic loop). Domain Knowledge teaching is what makes that loop trustworthy in your domain — so the model composes the right next steps instead of inventing them from general memory.

This post is for two audiences: people building MCP servers who want agents to use their tools safely, and people wiring multi-agent stacks (or Agent Skills) on top of those servers who need to know what belongs in a system prompt versus what must ride every tool result.

The delivery split

How Domain Knowledge is delivered matters as much as how it is authored. Illustrating with a simple e-commerce stack (customers → orders → shipping / help articles); the same split applies to any domain MCP:

Static teaching — stable Domain Knowledge (funnel, core enums, policy). Loaded once per session or agent role.
Dynamic / just-in-time teaching — observation-local Domain Knowledge: scope and next steps for this result. Travels with the tool response.

Dynamic teaching has two practical implementations.

Structured fields — machine-actionable truth (status, next-step arguments, ids, closed codes).
Contextual hints — short, data-driven English (agentHints) assembled only when this payload needs it.

Do not treat Skills or system prompts as a substitute for the response-local half.

Static Domain Knowledge: MCP first

On the MCP server (portable contract)

Channel	Role
MCP server instructions	Short shared core: resolve funnel, core grades/enums, “act from structured fields; follow hints when present”
Tool descriptions	Dense per-tool how-to — size-capped and always-on in context, so summary, not an encyclopedia

Every consumer of the server gets tools when connected. Server instructions are weaker than that sounds. The MCP spec treats them as optional (clients MAY surface them), so support varies:

OpenAI Codex — documents support, but does not reliably expose them as server-wide agent guidance (often demoted to namespace metadata).
Claude Desktop / Claude.ai — silently drop server instructions, Claude Code honors them.

Static text that does land still has a budget. Hosts such as Claude truncate server and tool descriptions around ~2 KB each. Whatever you ship there is loaded into the model context for the session — so an encyclopedia burns tokens on every turn, with inference speed and cost consequences even when the agent never needs that paragraph.

Put a short shared core in server instructions and mirror essentials in tool descriptions. Treat instructions alone as insufficient. Prefer case-local structured fields and hints for the long tail: they ride every call without bloating always-on context.

Off the MCP server (useful, not sufficient)

Channel	Role
Agent Skills (`SKILL.md`)	Task-level progressive disclosure: host loads metadata - agent pulls the body when the task looks relevant
Multi-agent system prompts	Role packaging: “you are the orders / fulfillment specialist” — stable playbook for that agent only

The usual vendor split is right as far as it goes: MCP connects; Skills teach procedures. In a multi-agent stack the same idea shows up as orchestrator and specialist system prompts. Both are good homes for the static guide of a given agent. Both are weak for “explain this rare code” or “follow these related ids” — they load for a task or role, not for this tool result.

Two delivery traps today:

Skills ≠ MCP install. Enabling a MCP server does not install a companion Skill. Until Skills ship with the MCP server (in progress), Skill-only teaching is optional and unreliable.
System prompts are private. A specialist’s prompt is invisible to every other client of the same MCP. If correct interpretation depends on that prompt alone, the portable contract is broken, knowledge is fragmented and may be inconsistent.

Why the static slice is not enough

Static Domain Knowledge is usually authored as natural language — server instructions, tool descriptions, Skills, system prompts. A happy-path guide reads like this:

Resolve the customer first, then list orders for that customer.
If resolve returns status need_order, ask which order they mean —
show recentOrders; do not invent an order id.
Order status is the source of truth for fulfillment; help articles
explain policy, they do not override status.
Prefer structured fields on the tool result; follow agentHints when present.

That works for the stable funnel. Reality adds storefront-specific scope, optional filters not yet pinned, rare answer-shaping flags, and bridges to sibling domains (shipping, returns, payments) that only matter when related ids are present in the data. Encoding every case in always-on instructions produces an encyclopedia that burns context every turn, still misses the rare code that is not on this call, and fails for callers that never saw your Skill or system prompt. Those cases need teaching on the tool result itself.

Dynamic Domain Knowledge on the tool result

Industry names for this half vary — progressive disclosure, just-in-time instructions, tool-response steering, next-action hints. In Knowledge Engineering terms: put the rule next to the case. It can be implemented as two layers on the tool result:

Walk the same short conversation through both layers.

User: “What’s the status of my order?”

Structured fields (primary)

Machine-actionable truth the agent can act on even if it ignores English: workflow status, ready-made next-call args, closed codes, thin stubs for a follow-on tool.

Tool: resolve_customer

{
  "status": "need_order",
  "askNext": "orderId",
  "recentOrders": ["ORD-1042", "ORD-1038", "ORD-1021"],
  "listOrdersArgs": { "customerId": "cust_9f3a" }
}

The next hop is in the payload: ask which order, or call list_orders with customerId already filled — no extra always-on instructions required.

User: “The latest one — ORD-1042.”

Tool: get_order

{
  "orderId": "ORD-1042",
  "status": "shipped",
  "shipmentStub": { "trackingId": "1Z999", "carrier": "ups" },
  "relatedDocs": { "count": 2, "preferredId": "kb-returns-eu" }
}

Stubs (shipmentStub, relatedDocs) are portable ids for later joins — still on this orders MCP. Following them onto sibling servers is the next section.

Contextual hints (reinforcement)

Short, data-driven English assembled only when this payload needs it — not a glossary pasted on every call. Replay the same two turns with agentHints added — still on the orders MCP.

Opening turn — resolve_customer:

{
  "status": "need_order",
  "askNext": "orderId",
  "recentOrders": ["ORD-1042", "ORD-1038", "ORD-1021"],
  "listOrdersArgs": { "customerId": "cust_9f3a" },
  "agentHints": [
    "Ask which order they mean. Show recentOrders. Do not invent an order id.",
    "This customer resolved on the EU storefront only — do not merge US marketplace orders into the same answer."
  ]
}

After the user picks ORD-1042 — same get_order, with a rare-code gloss when the user asks for an ETA:

User: “When will ORD-1042 arrive?”

Tool: get_order

{
  "orderId": "ORD-1042",
  "status": "shipped",
  "flags": ["etaUnknown"],
  "shipmentStub": { "trackingId": "1Z999", "carrier": "ups" },
  "relatedDocs": { "count": 2, "preferredId": "kb-returns-eu" },
  "agentHints": [
    "etaUnknown: carrier accepted the parcel but has not published a delivery window — say in transit, do not invent a date."
  ]
}

Core statuses (placed / shipped / delivered / …) stay in the static guide once. Behavioral gloss fires when the answer-shaping code is present. Hints are not a dump of every tally in the payload.

Connecting company data across domains

Enterprises rarely keep one system of record. Orders, shipping, payments, returns policy, inventory — often different teams, different APIs, and increasingly different MCP servers (or specialist agents) in the same stack.

Static manuals that say “also try the shipping server” on every turn are noise. Dynamic teaching is a practical join layer for the workflow engine:

Structured fields carry portable ids, stubs, and counts, but only when a cross-domain link is in scope.
Contextual hints say when and why to follow them — and what not to overwrite (e.g. help articles do not replace order status).

Continuing after the agent said ORD-1042 is in transit with no ETA. The orders payload already had stubs; now hints say when and why to leave this MCP:

{
  "agentHints": [
    "Tracking exists — call get_shipment on the shipping MCP with trackingId.",
    "Returns policy is in relatedDocs; call get_help_article — it does not override order status."
  ]
}

User: “OK — where is the parcel right now, and what’s my return window?”

Tools: get_shipment (shipping MCP) and get_help_article (help MCP):

// get_shipment
{ "trackingId": "1Z999", "lastScan": "Brussels hub", "state": "in_transit" }

// get_help_article
{ "id": "kb-returns-eu", "title": "EU returns — 30 days from delivery", "body": "EU return policy is ...." }

Structured stubs + hints teach the join; sibling servers answer the detail. An orchestrator or sibling agent can act on those cues even if it never shared your Skill: the bridge rides the tool result, not a private system prompt.

You are not federating every backend into one payload. You teach the next hop across company Domain Knowledge boundaries — whether the follow-on lives on this MCP, another MCP, or another agent.

Can a Skill or system prompt replace dynamic teaching?

No — not for the case-local half. Skills and system prompts are fine for packaging the static guide (“you are the orders agent; resolve customer first”). They are a poor home for “explain this etaUnknown” or “follow these related ids.”

Why, briefly:

Agent loads Skill when the task looks relevant; a system prompt loads for the Agent role. Neither sees what is on this tool result unless you paste every edge case into the prompt.
Encoding those edge cases as a long “if status X and flag Y…” Skill burns context and is easy to mis-apply — especially on smaller models. Hints are already matched to the payload.
Skills and prompts do not invent status / next-step fields. Those have to come from the tool.
Other callers of the same MCP (evals, APIs, sibling agents) never see your prompt. Teaching that must always work has to ride the response.

Use Skills / prompts as optional packaging of the static core. Keep dynamic teaching on the wire.

How the pieces fit

Static guide / Skills / system prompts  →  how the domain usually works
Response Structured fields              →  what to do next (primary)
Response Contextual hints               →  this result only — rare codes, scope, next MCP hop

Put the stable funnel and core statuses in the MCP static guide (and optionally in a Skill or agent prompt). Put product- or case-specific routing, rare-code glosses, and cross-domain bridges on the tool result — structured fields first, hints as reinforcement.

For anything the agent must get right:

Tool descriptions (plus server instructions when the client honors them) — what hosts actually surface; keep them short (~2 KB caps, always-on context cost).
Structured fields + hints on results — guaranteed every call, scoped to the answer.
Skills / System prompts — nice for a given host or role; never the only place correct interpretation lives.

Later, if hosts ship Skills with the MCP server, more of the static guide can move there. Keep response-local fields and hints for facts that exist only on the current result.

For MCP server builders

Treat Domain Knowledge delivery as part of the API contract — Knowledge Engineering for agents, not only schema design:

Author a short static core in server instructions and tool descriptions — do not rely on instructions alone (Codex / Claude Desktop gaps above).
Design responses for agents: closed codes, next-step args, thin stubs for follow-on tools.
Assemble contextual hints from the payload — skip empty glossaries.
Keep case-specific sentences out of the static manual when they can be stamped onto the response.
Emit cross-domain bridges as data + hints when a join is in scope.
Document Skills / multi-agent prompts as optional packaging of the same static core — not as the home of rare-code explanations.

One MCP surface then works for a lone IDE agent, a CI eval, and a specialist inside a multi-agent orchestrator. Static Domain Knowledge can be thinned per host; the dynamic slice — including cross-domain next hops — stays on the wire.

Conclusion

MCP gives agents tools. Domain Knowledge teaching keeps them from misreading the answers, fuels what modern models are trained to do well — the agentic loop over those tools — and helps that loop join company data across domains, even when each domain is served by a different MCP server or specialist agent.

That is Knowledge Engineering in practice: capture how the domain should be reasoned about, then place each piece where the agent will see it. Stable model → static channels (MCP first; Skills and system prompts optional). Case-local truth → dynamic channels on every result (structured fields primary, contextual hints as reinforcement).

It also helps smaller and cheaper models stay on the rails: they get the next hop and rare-code gloss on the payload instead of reconstructing a long playbook from a bloated static prompt. Same workflow quality, lower inference cost.

Start with that split and let just-in-time Domain Knowledge ride the tool response. Feedback welcome if you try the pattern on your own domain tools.

Authenticated Machine-to-machine MCP without the OAuth puzzle

Vlastimil Elias — Fri, 24 Jul 2026 13:12:52 +0000

MCP Authorization spec and most MCP clients assume a human is present: open a browser, consent, get a token, keep going until the session expires, then repeat. That model breaks as soon as you want an autonomous agent, a CI job, a daemon, or any other long-running process that must talk to an OAuth-protected MCP server with nobody at the keyboard.

mcp-client-credentials-auth is a local MCP authentication proxy for that gap. It sits between your MCP client and a remote MCP server, obtains tokens with the OAuth client_credentials grant (MCP OAuth Client Credentials extension Draft), and forwards MCP traffic with a Bearer token. Your MCP client keeps talking plain unauthenticated MCP, and the proxy handles authentication.

This post is for two audiences: people who need machine access to a remote MCP server today, and MCP server providers who want a ready client path to recommend for that access.

To use it, the MCP server provider must support machine auth via OAuth client_credentials. In practice that means a service account (sometimes labeled "API key", "machine-to-machine application", or similar) with a client_id and client_secret that their OAuth setup accepts for this grant. Creating those credentials is often self-service in the provider's account or developer portal, or they are handed out on request. Interactive-only servers (browser login / user consent only) are out of scope for this proxy.

The use case

Use it whenever the caller is a machine, not a person, and the remote MCP provider offers that service-account style access:

Autonomous agents and background workers that need tools, resources, or prompts from a protected remote MCP
CI/CD pipelines and ops automations
Server-to-server integrations and long-running processes where human may not be at the keyboard

You can also use it when you are tired of unoptimal interactive authentication UX in MCP clients, when you can easily miss that MCP server is not authenticated, and you do not have access to the tools anymore.

Once you have credentials from the provider, point the proxy at the remote MCP URL and drop it into your MCP client config. The proxy acquires acsess tokens, refreshes them proactively, reconnects when the remote MCP server flaps, and stays transparent to the protocol.

Installation that stays simple (because discovery works)

Well-behaved MCP servers publish MCP Authorization metadata (RFC 9728 / RFC 8414). The proxy follows that discovery path, so you normally do not hand-configure a token endpoint or invent scopes.

Typical setup in an MCP client such as Cursor or Claude Code is three environment variables:

{
  "mcpServers": {
    "my-remote-server": {
      "command": "npx",
      "args": ["-y", "mcp-client-credentials-auth"],
      "env": {
        "MCP_CC_PROXY_REMOTE_MCP_URL": "https://mcp.example.com/mcp",
        "MCP_CC_PROXY_CLIENT_ID": "my-service",
        "MCP_CC_PROXY_CLIENT_SECRET": "s3cr3t"
      }
    }
  }
}

That is the whole install for the common path: remote MCP server URL + client_id + client_secret. Discovery finds the IdP token endpoint and the baseline scopes. The proxy fails closed at startup if auth or the remote cannot be made ready, so you do not get a green local session that dies on the first real call.

npx downloads and runs the published package on your machine, so use trusted packages only (same caution as any other npx MCP server).

If a server accepts Bearer tokens but does not publish discovery, you can still run with a manual token endpoint and scopes (MCP_CC_PROXY_TOKEN_ENDPOINT and usually MCP_CC_PROXY_SCOPES). Those values must come from the MCP server provider's documentation, do not try to invent them. Prefer auto-discovery when the MCP server supports it.

Two deployment options

1. Local stdio (default): one client, one proxy process

This is the install path above. Your MCP client spawns the proxy over stdio (proxy acts as local MCP Server) on the same machine, and the proxy talks outbound HTTPS to the remote server with Bearer auth. Each user (or agent host) should use their own service-account credentials, not a shared org-wide secret copied into every laptop config.

Viable when:

A single MCP client (IDE, agent host, CLI) can spawn a local MCP Server process
Each user can obtain (or be issued) their own client_credentials client
You want the smallest attack surface: no local network listener
Credentials stay on that machine / in that client's secret store

Prefer stdio whenever one client can own the proxy lifecycle. It is the right default for Cursor, Claude Desktop, Claude Code, and similar local setups.

2. On-premises HTTP: one shared proxy and identity for several clients

Set MCP_CC_PROXY_TRANSPORT=http. The process listens for Streamable HTTP so multiple MCP clients on a private network can share one outbound client_credentials identity. A container image is also available with HTTP as the default transport and k8s style health checks for easy deployment.

Viable when:

Several MCP clients on a trusted private network should share one machine identity
You do not want to install or spawn the proxy on every workstation
A single MCP client (IDE, agent host, CLI) can't spawn a local MCP Server process but has to use remote one

HTTP mode has no TLS or inbound authentication on the proxy itself, see Security considerations.

Situation	Choose
One client can spawn a local MCP server process, and each user has their own OAuth client	Local stdio
Many clients or no local MCP Server support, one shared M2M identity on a private network	On-premises HTTP
Public internet or untrusted callers	Not recommended for either mode

What you get beyond "it connects"

Transparent bidirectional MCP forwarding
Identity and capability forwarding (your client sees the remote server's real name and capabilities, including server-to-client features such as sampling and elicitation)
Proactive access token refresh and 401 retry behavior
Scope step-up when the remote challenges with 403 insufficient_scope
Streamable HTTP with SSE fallback for connection-class failures
Automatic reconnection and stale remote session recovery
Optional call audit log (on by default in HTTP mode)
Categorized errors (authentication / connection / remote) with detailed messages for easier troubleshooting
Fail-closed startup: the local transport binds only after auth is ready and the remote MCP server is reachable, so your MCP client shows a correct status

Security considerations

A few rules of thumb matter more than the feature list:

Treat the service account as powerful. Whoever holds client_id / client_secret (or can reach an HTTP-mode proxy that already has them) gets that remote privilege. Prefer per-user clients for stdio, and rotate on compromise.
Prefer vaults over plain-text MCP config. The install snippet above shows secrets in environment variables for brevity. In production, inject client_id / client_secret at launch from 1Password, Bitwarden, a cloud secret store, or similar, instead of leaving them in an MCP config file on disk.
Keep the proxy private. Stdio has no network listener. HTTP mode is for trusted private networks only: recommended to terminate TLS and inbound auth at a reverse proxy, ingress, or MCP gateway. Never publish the listener to the public internet.
HTTP mode is one shared machine identity. All MCP clients reuse the same outbound Bearer token and scopes. It is not a multi-tenant edge, so use separate deployments per trust boundary.
The proxy owns the outbound Authorization header. Access tokens stay in memory and are never logged, and the local MCP client cannot supply or override the Bearer token used toward the remote server.

More detail is in the repo Security section.

For MCP server providers

If you already protect your MCP server with OAuth for interactive clients, your users will still ask how agents, CI, and other headless callers should authenticate. You do not need to ship a custom M2M client for every IDE and agent host. Document this proxy as the supported way to get service-account access: users create (or receive) a client_id / client_secret, point the proxy at your MCP URL, and keep using their existing plain MCP client.

That works best when your product already exposes machine credentials and standard MCP Authorization discovery:

Publish protected resource / authorization server metadata so the proxy can find your token endpoint and baseline scopes
Offer a service account (or equivalent) granted those baseline scopes for client_credentials
Prefer a short setup guide: remote URL + credentials (+ this proxy), not a DIY OAuth client walkthrough

Users then get secure, long-term, non-interactive service-account access without building token acquisition themselves. You keep one OAuth-protected MCP surface for both human consent flows and machine callers, and you point the machine path at a known, discovery-friendly client instead of fragmented one-off scripts.

If discovery is not available yet, you can still recommend the proxy, but document the necessary settings yourself: the IdP token endpoint URL and the scopes to request (MCP_CC_PROXY_TOKEN_ENDPOINT and MCP_CC_PROXY_SCOPES). Users cannot discover those without your guidance. Auto-discovery remains the smoother story when you can publish it.

For more detail see notes for MCP Server Developers

Conclusion

If you run OAuth-protected MCP for agents or pipelines, or you operate an MCP server and want an easy M2M client path for your users, start with discovery plus service-account credentials and let the proxy handle the rest on the client side. Feedback and issues are welcome on the repo.

Bridge the gap between your IdP and the MCP World

Vlastimil Elias — Fri, 15 May 2026 14:23:40 +0000

So you've got your corporate IdP (Keycloak, Auth0, Okta, Azure AD, whatever) and now you want your MCP servers to use it for auth. You point Claude Code or Cursor at it, aaand... things break. Scope explosions on the consent screen, missing PKCE defaults, clients demanding Dynamic Client Registration your IdP doesn't serve the way MCP expects. Sound familiar?

The problem

The MCP Authorization spec expects certain OAuth behaviors that most enterprise IdPs don't provide out of the box:

MCP clients expect open Dynamic Client Registration. Most IdPs either don't expose it or lock it behind admin credentials.
MCP clients tend to request all announced scopes. This isn't required by the spec - it's just how most clients (Claude Code, Cursor, others) behave in practice. They read scopes_supported from discovery and request all of them. Your Keycloak announces 15 internal scopes? Congrats, users now see a consent screen from hell - or the request gets rejected outright if client is not pre-approved for some announced scope.
Many clients add offline_access unconditionally. Again, not a spec requirement - just a common client behavior to ensure they get refresh tokens. This becomes a problem when your IdP restricts long-lived refresh tokens or requires client pre-approval for that scope.
Discovery metadata needs filtering. IdPs expose dozens of OIDC fields (CIBA, device flow, logout endpoints...) that are irrelevant noise for MCP and can confuse clients.

You could customize your IdP, but that's a maintenance rabbit hole - especially when you need the same IdP for non-MCP and legacy apps.

Enter mcp-auth-adapter

mcp-auth-adapter is a thin, stateless Node.js proxy that sits between your MCP clients and your existing IdP. It doesn't issue tokens or handle authentication - all the real work stays on your IdP. It just makes the OAuth dance MCP-compatible.

What it does

Filtered discovery - Serves /.well-known/ IdP metadata with only the fields MCP clients actually need. Injects safe defaults (PKCE S256, authorization_code grant) when your IdP's metadata is incomplete, and own functionality where needed.

Open DCR endpoint - POST /register hands out a fixed, pre-configured client_id so MCP clients can self-register. No IdP-side DCR needed.

Scope filtering - Control what scopes reach your IdP. Strip offline_access, remove internal scopes, or use an allowlist:

# Only these scopes will ever reach the upstream IdP
MCP_PROXY_AUTH_SCOPES_PRESERVED=openid,api.read,api.write

CIMD support (experimental) - The MCP spec defaults to Client ID Metadata Documents for client identification, but it's an emerging IETF draft (not yet RFC) and no major IdP supports it natively today. This adapter bridges that gap - it accepts CIMD-style client_id URLs from MCP clients, validates the metadata documents, and maps them to real upstream client_ids your IdP understands. So you get CIMD compatibility without waiting for your IdP vendor to implement it.

Observability built in - Prometheus metrics at /metrics, structured logging, health probes for k8s.

Deploy it in 30 seconds

Grab the container image and go:

docker run -d --name mcp-auth-adapter \
  -p 3000:3000 \
  -e MCP_BASE_URL=https://mcp-auth.example.com \
  -e MCP_UPSTREAM_SSO_URL=https://sso.example.com/auth/realms/external \
  -e MCP_PROXY_DCR_CLIENT_ID=mcp-client \
  ghcr.io/velias/mcp-auth-adapter:latest

That's it. Three env vars for a basic setup:

MCP_BASE_URL - the public URL where this adapter lives
MCP_UPSTREAM_SSO_URL - your IdP's issuer URL
MCP_PROXY_DCR_CLIENT_ID - a public client pre-registered at your IdP

Then point your MCP server's authorization_servers to MCP_BASE_URL and clients will discover everything via .well-known.

Typical production config

For a real deployment you'll probably want scope control too:

MCP_BASE_URL=https://mcp-auth.example.com
MCP_UPSTREAM_SSO_URL=https://sso.example.com/auth/realms/external
MCP_PROXY_DCR_CLIENT_ID=mcp-client
MCP_WELL_KNOWN_SCOPES_SUPPORTED=openid,api.read,api.write
MCP_PROXY_AUTH_SCOPES_REMOVED=offline_access

This controls both sides: what clients see in discovery and what actually reaches your IdP.

What it doesn't do

This adapter is intentionally minimal:

No token issuing - tokens come from your IdP, always
No user database - stateless, nothing to back up
No rate limiting - put it behind your existing reverse proxy / WAF
No CORS - designed for redirect-based flows, not browser fetch calls

Who is this for?

If you're running MCP servers (or planning to) and have an existing OAuth/OIDC provider, this saves you from bending your IdP config to accommodate MCP client quirks. Works with Keycloak, Auth0, Okta, Azure AD/Entra, Google Identity - anything that serves standard OIDC discovery.

Tested with Claude Code, Claude Desktop, Cursor IDE, Cursor Agent, Gemini CLI, VS Code, and more.

Wrapping up

MCP is moving fast, and auth is one of those things that should just work but often doesn't when you try to connect real-world IdPs to real-world MCP clients. Instead of fighting your IdP config or waiting for vendors to catch up with emerging standards like CIMD, drop a lightweight adapter in between and move on to building the actual MCP tools your users care about.

If you hit rough edges or have ideas, open an issue - the project is young and feedback shapes the roadmap.

Apache 2.0 licensed. PRs welcome.

GitHub: github.com/velias/mcp-auth-adapter

DEV Community: Vlastimil Elias

Domain Knowledge for AI agents: static vs just-in-time teaching

The delivery split

Static Domain Knowledge: MCP first

On the MCP server (portable contract)

Off the MCP server (useful, not sufficient)

Why the static slice is not enough

Dynamic Domain Knowledge on the tool result

Structured fields (primary)

Contextual hints (reinforcement)

Connecting company data across domains

Can a Skill or system prompt replace dynamic teaching?

How the pieces fit

For MCP server builders

Conclusion

Further reading

Authenticated Machine-to-machine MCP without the OAuth puzzle

The use case

Installation that stays simple (because discovery works)

Two deployment options

1. Local stdio (default): one client, one proxy process

2. On-premises HTTP: one shared proxy and identity for several clients

What you get beyond "it connects"

Security considerations

For MCP server providers

Links

Conclusion

Bridge the gap between your IdP and the MCP World

The problem

Enter mcp-auth-adapter

What it does

Deploy it in 30 seconds

Typical production config

What it doesn't do

Who is this for?

Wrapping up