In the my team and I had very limited knowledge of MCP servers and add to discover the topic, and learn it while (vibe)coding the Proof of Concept.
It turned out that creating an MCP server with STDIO transport is really trivial. Especially thanks to
Phase 2: From stdio to HTTP
STDIO is great for local use, but we needed the server accessible over the network. The goal: connect non-technical colleagues using for remote access:
docker build -t mcp-server .
docker run -p 8000:8000 -e API_TOKEN=${API_TOKEN} mcp-server
# In another terminal - expose to the internet for testing
ngrok http 8000
The MCP Inspector
Throughout all of this, the to test your APIs. You see exactly what the AI sees: tool names, descriptions, parameter schemas, and responses. If something doesn't work in Claude or Kiro, the Inspector tells you whether the problem is your server or the client.
We used it constantly - to validate tools, debug response formats, and understand what was actually happening under the hood. For local development, the workflow was simple: run the server in Docker, point the Inspector at http://localhost:8000/mcp, and iterate.
Phase 3: Where Do You Actually Run This Thing?
With the Dockerized version working locally, the question became: where do we deploy it?
We had a working container. Now we needed it accessible to multiple users - colleagues testing with Langdock, AI tools connecting remotely, potentially customers down the line. ngrok was fine for a demo, not for anything persistent.
We considered a few options:
AWS Lambda Serverless, pay-per-invocation, no infra to manage. But the interaction with an MCP servers could mean a conversation envolving multiple tool calls. Every new request could spin up a (potentially cold) Lambda, adding latency. Costs could also spike quickly with many short-lived invocations.
EKS (our existing cluster) We already run workloads on EKS, so deploying another pod would have been trivial. But it raised questions considering the long-run: all users hitting the same pod means shared state. Could potentially user A's conversation context leak into user B's session? Even without explicit state, things like connection pools, cached tokens, or in-memory variables could bleed across requests. We'd need to think seriously about multi-tenancy, resource isolation, and session boundaries before putting this anywhere near real users.
Just a few months before AWS launched AWS AgentCore Runtime: a managed service specifically designed to host MCP servers and AI agents. Serverless, auto-scaling, built-in Cognito auth, CloudWatch observability, MCP protocol support out of the box.
We went with AgentCore. The whole point of this PoC was to explore - not just proving "it works" but surfacing the hard questions early. EKS would have taken 30 minutes and given us a green checkmark. But it would have also given Product and management a false sense of confidence: everything's sorted, production is around the corner. In reality, we'd have kicked authentication, multi-tenancy, cost, and operational concerns down the road; exactly the kind of surprises that blow up timelines later.
A PoC that only validates the happy path isn't a PoC.
We wanted to learn how and even the to point at the AgentCore URL with the Bearer token:
{
"name": "Accounting MCP server",
"url": "https://bedrock-agentcore.eu-central-1.amazonaws.com/runtimes/arn%3Aaws%3Abedrock-agentcore%3Aeu-central-1%3A257174212998%3Aruntime%2Faccounting_server_http-nfZ30p98Ct/mcp?qualifier=DEFAULT",
"transport": "streamable-http",
"authentication": {
"type": "bearer",
"token": "eyJraWQiOi..."
}
}
And it worked. Non-technical colleagues could configure the MCP server in Langdock and chat with the AI to get real accounting data back. The PoC was validated end-to-end.
But it immediately surfaced the next problem.
The Unsolved Question: How Do Customers Get the Token?
In our PoC, we (the developers) generated the token by running a shell script, then pasted it into Langdock's config. That's not a customer workflow - it's a developer hack.
# refresh_token.sh - "log in" to Cognito, get a fresh JWT
export BEARER_TOKEN=$(aws cognito-idp initiate-auth \
--client-id "$CLIENT_ID" \
--auth-flow USER_PASSWORD_AUTH \
--auth-parameters USERNAME=$COGNITO_USERNAME,PASSWORD=$COGNITO_PASSWORD \
--region eu-central-1 | jq -r '.AuthenticationResult.AccessToken')
The token expires every hour. When it did, someone had to re-run the script and paste the new token. Non-technical people can't do that - they don't have AWS CLI access, they don't know what a Bearer token is, and they shouldn't have to.
On top of that, the MCP server itself still needs our API token to call the downstream accounting API, currently baked into the container as an env var. So you have two auth layers: Cognito for accessing AgentCore, and the API token for the upstream system. For a real product, we'd need to connect our actual Cognito pools (the ones our main app uses for customer login) so that the same login mechanism gives users a Bearer token for AgentCore and the credentials to invoke the underlying API.
Think of it this way: AgentCore's customJWTAuthorizer is like putting a lock on a door. We proved the lock works. But we haven't built the key-dispensing machine for customers yet. In the PoC, we were the locksmith - we made the key ourselves with CLI tools.
What about AgentCore Identity?
We initially thought this might be the answer, but it's not. AgentCore Identity is designed for the agent accessing external services on behalf of users (e.g., your agent calling GitHub with the user's OAuth token). It solves a different problem: agent-to-service auth, not user-to-agent auth.
So what would a production-ready solution look like?
Unfortunately we don't know yet. When we were working on the PoC it was late December, Christmas was around the corner, and we'd proven enough to present the results internally.
When January came, a major organisational change completely shifted our priorities. The PoC was left in this state: working, demonstrated, but with the final authentication mystery unsolved. Maybe one day we'll pick it back up. For now, it remains an open question, although we do have a couple of options to evolve the poc:
the app issues the token. Customer logs into your existing product (your CIAM). Your backend generates a JWT and returns it. You expose a "Get MCP Token" button in your app's settings page. Customer copies it into their MCP client config. Still manual copy-paste, but at least the customer doesn't need AWS access. Token refresh could be automated via your app's UI.
OAuth2 flow in the MCP client. The MCP client (Langdock, Claude, etc.) supports OAuth2 natively - clicking "connect" opens a browser, customer logs in via your login page, the token flows back automatically. No copy-paste at all. This is how the work. But it requires the MCP client to implement the OAuth redirect flow, and your identity provider to support it.
There's also the ugly URL problem. You can't exactly hand customers https://bedrock-agentcore.eu-central-1.amazonaws.com/runtimes/arn%3Aaws%3A.../mcp?qualifier=DEFAULT and call it a day. AWS published a .
The idea is compelling: instead of writing MCP tool wrappers by hand, you feed your OpenAPI spec to the Gateway and it generates MCP tools automatically.
agentcore gateway create-mcp-gateway \
--name accounting-gateway \
--region eu-central-1
agentcore gateway create-mcp-gateway-target \
--gateway-arn <arn> \
--target-type openApiSchema \
--target-payload file://our-openapi.yaml
No custom Python code. No FastMCP. The Gateway reads your API spec and exposes each endpoint as an MCP tool.
In practice, it didn't go smoothly either. Our OpenAPI spec was large and not perfectly RESTful - the Gateway choked on it. The solution was to extract a subset of endpoints manually.
He also built the full infrastructure with Terraform (Runtime, Gateway, Memory, IAM, ECR) - which gave us a reproducible setup but added complexity.
We instead chose the ):
CPU: $0.0895 per vCPU-hour - but only for actual CPU consumption. If your agent is idle waiting for an API response, CPU charges stop.
Memory: $0.00945 per GB-hour - charged for peak memory consumed up to that second, with a 128MB minimum. Unlike CPU, memory billing doesn't pause during I/O wait - your container's memory footprint is always counted.
The key nuance: billing spans the entire session lifetime - from microVM boot to session termination. Sessions stay alive for the configured idle timeout (default 15 minutes) after the last request. So even if your tool call takes 2 seconds, the session (and its memory billing) continues for another 15 minutes waiting for the next request.
In our case: 19 sessions × 15 minutes idle each = nearly 5 hours of memory billing for what amounted to a few minutes of actual work. Our breakdown was roughly:
- Memory: 9.3 GB-hrs × $0.00945/GB-hr ≈ $0.09
- CPU: 0.1 vCPU-hrs × $0.0895/vCPU-hr ≈ $0.01
- Plus system overhead billed on top of your application's usage
Important update: The pricing model has evolved since our initial PoC. AWS now bills based on active consumption rather than pre-allocated resources - meaning I/O wait time (waiting for LLM responses, API calls) is free for CPU. This is a significant improvement over traditional compute pricing. Our early experience was with the previous billing model, so your mileage may vary. Always check the
Custom Domain Names for AgentCore Runtime
↗ Original-Artikel auf dev.to lesenVollständiger Original-BerichtAusführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.
SOCIAL SHARE CARD GENERATOR