DEV Community

Cover image for MCP Server on Bedrock AgentCore: What "Stateless Writes" Actually Forces You Into
Eugene Orlovsky
Eugene Orlovsky

Posted on Originally published at perfsys.com

MCP Server on Bedrock AgentCore: What "Stateless Writes" Actually Forces You Into

We just shipped an MCP server on Amazon Bedrock AgentCore Runtime that handles AWS Marketplace seller operations, private offers, change sets, the whole thing. Along the way we hit a constraint that reshaped the entire write path, and it's worth sharing on its own.

The problem: releasing a private offer moves real money, so we wanted a hard rule, nothing gets submitted that a human hasn't reviewed first. The obvious fix is a pending-operations table: client previews, server stores the payload, client confirms by ID.

That design doesn't survive AgentCore. Runtime is stateless with per-session microVM isolation, so there's no reliable place to keep a "pending" operation between two calls. Adding a database just to hold something for thirty seconds felt wrong too.

So instead of storing the confirmation, we made it derivable:

def token(changes, entity_version):
    """Deterministic, so no server-side pending state is needed."""
    payload = json.dumps(changes, sort_keys=True, separators=(",", ":"))
    digest = hashlib.sha256(f"{payload}|{entity_version}".encode())
    return digest.hexdigest()[:16]
Enter fullscreen mode Exit fullscreen mode

Hash the exact change set together with the entity version it was built against. Three things fall out of that, none of which need storage:

  • You can't submit a change set that was never previewed, you'd have no way to produce a matching token.
  • Editing the change set after preview invalidates the token.
  • If the product changes underneath you between preview and submit, the entity version shifts and the token invalidates too.

Statelessness ended up making the design better, not worse.

That's one piece of it. The full writeup also covers:

  • Why "Bedrock AgentCore" doesn't actually include a model (Runtime is just container hosting with an MCP-shaped contract)
  • Three assumptions worth rechecking before you build extra infrastructure (a proxy in front of AgentCore, a Dynamic Client Registration shim, and copying CLI commands from slightly stale guides)
  • The undocumented Marketplace API traps that only surface after the whole offer is built and reviewed
  • What it actually costs to run (spoiler: CloudWatch logs cost more than compute if you're not careful)
  • Which of AgentCore's seven services we actually use, and why we skipped Memory, Browser, and Code Interpreter on purpose

Full article here: https://perfsys.com/blog/mcp-server-bedrock-agentcore-aws-marketplace/

Top comments (1)

Collapse
 
crdt_cto profile image
CRDT

The most interesting part here isn’t actually MCP or AgentCore it’s the decision to make authorization derivable instead of stateful.

The deterministic token is a clean fit for a stateless runtime because it binds three things together: the exact requested changes, the entity version, and the human review step. That turns the token into a compact proof that the operation being submitted is exactly the operation that was previewed.

I especially like the entity-version binding. Without it, you could have a valid confirmation for a change set that was correct five minutes ago but is no longer safe against the current state. Versioning makes the confirmation effectively optimistic concurrency control.

It also highlights a broader architecture principle: when infrastructure makes server-side state expensive or unreliable, don't automatically add a database. First ask whether the state can be represented as a deterministic, verifiable artifact.

The cost observation is another great reminder for agent infrastructure. Compute is often the obvious line item, while observability quietly becomes the expensive part once every agent interaction produces verbose logs.

This is exactly the kind of real-world constraint that makes an architecture writeup valuable less “here's how to deploy MCP” and more “here's what broke our assumptions and what we changed because of it.”

Great engineering lesson.

For technical discussions or collaboration: TG_coolsoftDev