Dynamodb Mcp Server Free

DynamoDB compatible MCP boto3 No AWS account

You wanted to learn single-table design. Four hours later you have an IAM role, a policy that denies something you can't identify, a us-east-1 table you'll forget to delete, and you still haven't written the first Query. The alternative — DynamoDB Local — solves the account problem by living on localhost:8000, where nobody else can see it and no AI assistant can reach it.

	DynamoDB Local	AWS DynamoDB	freebase.cloud
Runs where	your machine (JVM or Docker)	an AWS region	hosted, one HTTPS endpoint
AWS account, IAM, billing	none	required	none
Reachable from CI or a teammate	no	yes	yes
Reachable from an MCP client	no	not without a bridge	yes, natively
Streams, IAM, CloudWatch, autoscaling, backups	no	yes	no
Cost	free	free tier, then metered	free tier
Honestly best for	offline unit tests	production	learning, prototyping, agent access

The middle column is the real product and this doesn't replace it. If you're running a payments ledger, run it on AWS. If you're working out whether your access patterns survive a single table, the third column removes four hours of yak-shaving and adds an MCP endpoint, which is the part DynamoDB Local can't give you at all.

What's in here

A support-ticket system modelled as one table, because that's the canonical exercise and it's small enough to hold in your head.

examples/
  table-definition.json   the CreateTable payload, with a GSI
  create-table.sh         bash + aws CLI — create, describe, verify
  seed_tickets.py         Python + boto3 — items in five entity shapes
  query_patterns.py       Python + boto3 — every access pattern, one function each

Access patterns first

This is the whole discipline. In a relational database you model the entities and figure out the queries later. Here you write the list of questions down, on paper, before you name a single attribute — because the key schema is a direct function of that list and changing it later means rewriting every item.

For a support desk:

1. Fetch one ticket by id.
2. List every message on a ticket, oldest first.
3. List every ticket for a customer, newest first.
4. List open tickets assigned to an agent, by priority.
5. Fetch a customer's profile.
6. Find tickets breaching SLA across all customers.

Six questions. Now the keys.

One table, five entity types

PK and SK are deliberately meaningless names, because they hold different things depending on the row. That feels wrong for about a week and then stops.

Entity	PK	SK	Serves
Customer	CUST#<id>	PROFILE	5
Ticket	CUST#<id>	TICKET#<created>#<ticketId>	3
Ticket detail	TICKET#<id>	META	1
Message	TICKET#<id>	MSG#<timestamp>	2
Attachment	TICKET#<id>	FILE#<name>	1

Two things fall out of this immediately.

A ticket is stored twice. Once under CUST#… so pattern 3 is a single Query, once under TICKET#… so patterns 1 and 2 live in the same partition. That's not a mistake, it's the mechanism. Storage is the cheap resource; a second round trip is not.

Sort keys sort lexicographically, so timestamps must be ISO 8601. TICKET#2024-03-12T09:14:00Z#t-8871 sorts correctly as a string. TICKET#12/03/2024#t-8871 does not, and you will not find out until March becomes April.

Pattern 2 is now Query with PK = TICKET#t-8871 AND begins_with(SK, "MSG#"), ascending. Pattern 1 with SK = META. Pattern 3 with PK = CUST#c-114 AND begins_with(SK, "TICKET#"), ScanIndexForward=False for newest-first.

The GSI covers what the base table can't

Patterns 4 and 6 don't start from a customer or a ticket, so they need a second view. One global secondary index, keys overloaded the same way:

GSI1PK = AGENT#<agentId>        GSI1SK = <status>#<priority>#<created>
GSI1PK = SLA#<yyyy-mm-dd>       GSI1SK = <dueAt>#<ticketId>

Only items that need to appear in the index get GSI1PK written at all — a GSI is sparse, and items missing the index key are simply absent from it. That's a feature: your SLA index contains only tickets with an SLA, and it stays small.

Pattern 4 becomes Query GSI1 where GSI1PK = AGENT#a-3 AND begins_with(GSI1SK, "open#").

Setup

Create a free instance, pick the DynamoDB engine. You get an HTTPS endpoint that speaks the DynamoDB API, and an MCP endpoint over the same data.

For the AWS SDK and CLI

export DDB_ENDPOINT="https://freebase.cloud/api/wire/dynamodb"
export AWS_REGION="us-east-1"          # the SDK insists on one; the value is not meaningful here
export AWS_ACCESS_KEY_ID="local"       # likewise
export AWS_SECRET_ACCESS_KEY="local"

aws dynamodb list-tables --endpoint-url "$DDB_ENDPOINT" --region "$AWS_REGION"

import boto3, os
ddb = boto3.resource("dynamodb", endpoint_url=os.environ["DDB_ENDPOINT"], region_name="us-east-1")
table = ddb.Table("SupportDesk")

The --endpoint-url flag, pointed at your hosted instance, is the only change to code you'd otherwise write against AWS. Same request shapes, same response shapes, same pagination tokens.

For MCP

In the dashboard, open Settings → MCP, issue a New Token bound to this connection, and copy the endpoint. Because the token is a path segment rather than a header, clients that offer you nothing but a URL box still work.

claude mcp add --transport http tickets https://freebase.cloud/api/mcp/YOUR_TOKEN

// Cursor — .cursor/mcp.json
{ "mcpServers": { "tickets": { "url": "https://freebase.cloud/api/mcp/YOUR_TOKEN" } } }

// VS Code / Copilot Chat — .vscode/mcp.json, top-level key is "servers"
{ "servers": { "tickets": { "type": "http", "url": "https://freebase.cloud/api/mcp/YOUR_TOKEN" } } }

Claude Desktop, Claude web and Cowork add it through Settings → Connectors → Add custom connector; there's no config file path for remote servers. ChatGPT: Settings → Apps → Advanced settings → developer mode → Apps → Create, paste the URL, Auth None, Scan Tools. Developer mode is documented for Pro, Plus, Business, Enterprise and Edu; write access is still rolling out to the workspace tiers, so treat read as the dependable path for now.

Calling it from the OpenAI Responses API directly:

{
  "model": "gpt-5.6",
  "tools": [{
    "type": "mcp",
    "server_label": "tickets",
    "server_description": "Support desk single-table store — query and write tickets.",
    "server_url": "https://freebase.cloud/api/mcp/YOUR_TOKEN",
    "require_approval": "never"
  }],
  "input": "Which open tickets assigned to a-3 are highest priority?"
}

The four tools

Each connection gets the same four, prefixed with the name you gave it:

Tool	Arguments	Notes
tickets_query	query	Read path
tickets_store	table, rows[], mode	append or replace
tickets_list_tables	—	Tables, counts, attributes, annotations
tickets_annotate_table	table, description, format	Persists across sessions

For an overloaded single table the annotation is not optional. Without it a model sees a table with columns called PK and SK and has no way to know that PROFILE and MSG#… are different entity types. With it:

{
  "table": "SupportDesk",
  "description": "Single-table design. Five entity types share PK/SK; the SK prefix determines the type (PROFILE, TICKET#, META, MSG#, FILE#). Tickets are duplicated under CUST# and TICKET# on purpose — do not deduplicate. Never Scan this table; every access pattern has a Query.",
  "format": {
    "key_pattern": "PK=CUST#<id>|TICKET#<id>  SK=PROFILE|TICKET#<iso>#<id>|META|MSG#<iso>|FILE#<name>",
    "structure": "GSI1PK=AGENT#<id>|SLA#<date>, GSI1SK=<status>#<priority>#<iso>|<dueAt>#<ticketId>; sparse",
    "sample": { "PK": "TICKET#t-8871", "SK": "MSG#2024-03-12T09:20:11Z", "author": "agent:a-3", "body": "Replacement dispatched." }
  }
}

The sentence that saves the most trouble is "never Scan this table". Left alone, a model will Scan and filter, because that's what works in SQL. On a table with any real volume that's the expensive wrong answer.

Where this stops being AWS

Stated plainly, because a vague answer here wastes your afternoon:

• No IAM. No roles, no policies, no condition keys, no fine-grained access control on attributes. Your MCP token and endpoint are the only access boundary.
• No CloudWatch, no contributor insights, no on-demand backups, no PITR.
• No DynamoDB Streams, so no Lambda triggers hanging off item changes.
• No capacity modes. Nothing to provision, nothing to autoscale, and correspondingly no throttling behaviour to test against. If your application's retry logic depends on ProvisionedThroughputExceededException, you can't exercise it here.
• No global tables or cross-region replication.

What does work is the data-plane API surface you actually use while modelling: CreateTable with GSIs, PutItem, GetItem, UpdateItem, DeleteItem, Query, Scan, BatchWriteItem, TransactWriteItems, TransactGetItems, and full ConditionExpression syntax — attribute_exists, attribute_not_exists, begins_with, comparison operators. That's enough to build and validate the design; it isn't enough to certify a production deployment, and the free tier is scoped for development, prototyping and small workloads rather than for load testing.

FAQ

Is this AWS DynamoDB? No — it's a DynamoDB-compatible instance. Request and response shapes match the API reference, so SDK code moves across unchanged, but the AWS platform features listed above aren't there.

Can I point NoSQL Workbench at it? Yes. Add a connection with the freebase.cloud endpoint URL and any access key values.

Do transactions work? TransactWriteItems and TransactGetItems are supported, which matters if you're modelling the "create ticket and increment customer counter atomically" pattern.

What about the 400 KB item limit and other DynamoDB constraints? Design as if they apply. Portability back to AWS is the reason to use a compatible API at all, and a model that only works because a limit wasn't enforced isn't a model.

Can the agent delete my table? If it has the write tool, yes. Give agents a session that holds data you're willing to lose.

Links

• Free DynamoDB cloud instance
• Connect Claude to DynamoDB
• DynamoDB API reference
• Single-table design guidance
• Model Context Protocol

---

MIT licensed. freebase.cloud is an independent service and is not affiliated with Amazon Web Services, Inc., Anthropic, OpenAI, or Microsoft.