Two consequences follow from that. The good one: an assistant writing CDK code reads the reference for one known version, with no search step and nothing to get wrong about which release an answer came from. The one to plan for: a client that only speaks tools will show this server as empty, and the reference is only as current as the package you installed.
An MCP server that serves AWS CDK API reference documentation and integration-test sample code as resources. The documents are bundled into the released Python artifact rather than fetched, so it works with no network access — and returns the reference for a pinned CDK version rather than whatever a search engine surfaces.
- Two registered resources covering the two CDK namespaces — `cdk-api-docs://constructs/aws-cdk-lib` for the stable modules and `cdk-api-docs://constructs/@aws-cdk` for the alpha ones — discoverable by listing resources from your client
- The modules inside a package, then the documents inside a module, reachable by reading the templated URIs down one level at a time
- Integration test code alongside the API reference, so the answer to "how is this construct actually wired up" comes as working sample rather than a prose description
- The whole set offline: no API key, no rate limit, no drift between what you read and what the pinned version does
Nothing — no account, no key, no network at run time. Launch with `uvx konokenj.cdk-api-mcp-server@latest`; the package is `konokenj.cdk-api-mcp-server`. The bundled documentation tracks a specific CDK release, so refresh the package when you move CDK versions. Your client needs to support MCP resources rather than tools only, since everything here is exposed as resources.
One command — uvx konokenj.cdk-api-mcp-server@latest