The cloudcraft-mcp server provides an MCP interface to Cloudcraft.co, letting you manage cloud architecture blueprints and perform AWS live-scan snapshots from Claude Desktop or any MCP client.
User profile (whoami): Retrieve the authenticated user's profile to verify your API key.
List blueprints (list_blueprints): Get a summary of all blueprints in your account (id, name, tags, last updated).
Get a blueprint (get_blueprint): Fetch the full JSON details of a specific blueprint by UUID, including nodes, edges, groups, and layout.
Create a blueprint (create_blueprint): Create a new cloud architecture diagram from a JSON payload (EC2, S3, RDS, etc.).
Update a blueprint (update_blueprint): Replace the entire data payload of an existing blueprint.
Delete a blueprint (delete_blueprint): Permanently and irreversibly delete a blueprint by UUID.
Export a blueprint (export_blueprint_image): Render a blueprint to disk as PNG, SVG, PDF, or mxgraph, with optional scale and transparency settings.
List AWS accounts (list_aws_accounts): View all AWS accounts connected to Cloudcraft for live infrastructure scanning.
Snapshot AWS resources (snapshot_aws): Take a live-scan snapshot of a specific AWS service (e.g., EC2, S3, RDS, Lambda, VPC) in a given region from a connected AWS account.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cloudcraft-mcp List my Cloudcraft blueprints"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Unofficial Model Context Protocol (MCP) server for Cloudcraft — list, read, export, and build cloud architecture blueprints from Claude Desktop and other MCP clients.
Nine tools exposed to the MCP host:
Tool | Description |
| Return the Cloudcraft user profile for the configured key. |
| List every blueprint in the account. |
| Fetch a blueprint's full node / edge JSON. |
| Create a new blueprint from a JSON payload. |
| Replace an existing blueprint's payload. |
| Delete a blueprint (irreversible). |
| Render a blueprint to PNG / SVG / PDF / mxgraph on disk. |
| List AWS accounts connected for live-scan snapshots. |
| Take a live-scan snapshot of one AWS service. |
Related MCP server: AWS MCP Server
uv for the
recommended uvx and npm launchers
Node.js 22+ only when using the npm launcher
Cloudcraft API key — generate one at https://app.cloudcraft.co/ → User settings → API keys
Use an immutable version in client configuration so upgrades are deliberate.
Channel | Command |
PyPI / uvx |
|
pipx |
|
npm / npx |
|
Docker / GHCR |
|
Claude Desktop | Download |
uvx is delivered by the PyPI package; there is no separate uvx registry.
The npm package embeds the byte-identical Python wheel and invokes it through
uv, so the npm path requires both Node.js and uv. It does not download code
in a postinstall hook.
For development from a checkout:
git clone https://github.com/hypark5540/cloudcraft-mcp.git
cd cloudcraft-mcp
export CLOUDCRAFT_API_KEY='your-key-here'
uv run --frozen cloudcraft-mcp # Ctrl+C to exitInstall uv, then add this entry to Claude Desktop's configuration. Prefer Claude's secret storage when available; the literal below is only a portable example.
{
"mcpServers": {
"cloudcraft": {
"command": "uv",
"args": [
"tool",
"run",
"--isolated",
"--from",
"cloudcraft-mcp==0.1.6",
"cloudcraft-mcp"
],
"env": {
"CLOUDCRAFT_API_KEY": "your-key-here",
"CLOUDCRAFT_ENABLE_WRITES": "false",
"CLOUDCRAFT_ENABLE_DELETES": "false"
}
}
}
}Restart Claude Desktop. The Developer tab should show cloudcraft as connected.
See client setup for Cursor, Gemini CLI, npm, Docker, and MCPB examples.
Name | Required | Default | Purpose |
| yes | — | API key (Bearer). Generated in Cloudcraft User settings. |
| no |
| Override for proxies or future API versions. |
| no |
| Stderr log verbosity ( |
| no | private temp subdirectory | Directory that |
| no |
| Permit |
| no |
| Permit deletes when writes are also enabled. |
| no |
| Reject oversized Cloudcraft responses before they exhaust memory or disk. |
Once the server is connected, ask Claude things like:
"List my Cloudcraft blueprints and summarize what each represents."
"Export blueprint
f0086b32-...as PNG and save it to my Desktop."
"Take the architecture I just designed and create a new Cloudcraft blueprint called 'Prod 2026'."
"Snapshot the EC2 instances in
ap-northeast-2for my connected AWS account."
create_blueprint / update_blueprint accept the full Cloudcraft data object. A minimal payload:
{
"grid": "infinite",
"projection": "isometric",
"theme": {"base": "light"},
"version": 6,
"nodes": [
{"id": "...", "type": "ec2", "mapPos": [3, 3], "region": "ap-northeast-2",
"instanceType": "m7g", "instanceSize": "large", "platform": "linux"},
{"id": "...", "type": "s3", "mapPos": [1, 8], "region": "ap-northeast-2",
"volumeType": "Standard", "dataGb": 100}
],
"edges": [
{"from": "...ec2-id...", "to": "...s3-id...", "type": "edge",
"width": 2, "dashed": false, "endCap": "arrow"}
],
"groups": [], "surfaces": [], "text": [], "icons": [],
"connectors": [], "images": [], "disabledLayers": [],
"shareDocs": false
}Refer to Cloudcraft's API docs for the full node-type catalog and service-specific fields.
uv sync --extra dev
uv run pytest # unit tests (no network)
uv run ruff check . # lint
uv run mypy src # type checkTests mock the HTTP layer with respx so no API key is required.
CI uploads coverage.xml from the Python 3.12 matrix cell to
Codecov. The project gate
is 80% or higher — a PR that drops overall or patch coverage by more
than 1 percentage point below that line fails the Codecov check
(codecov.yml).
Run the same report locally:
uv run pytest --cov=cloudcraft_mcp --cov-report=term-missing --cov-report=xmlcloudcraft-mcp/
├── src/cloudcraft_mcp/
│ ├── __init__.py
│ ├── __main__.py # python -m cloudcraft_mcp
│ ├── server.py # MCP tool definitions (FastMCP)
│ ├── client.py # CloudcraftClient — async httpx wrapper
│ ├── types.py # TypedDicts for blueprint payloads
│ └── py.typed
├── tests/
│ └── test_client.py
├── bin/cloudcraft-mcp.mjs # npm-to-uv launcher
├── mcpb/manifest.json # Claude Desktop bundle metadata
├── server.json # official MCP Registry metadata
├── package.json # npm distribution
├── server.py # back-compat shim -> cloudcraft_mcp.server:main
├── pyproject.toml
├── LICENSE
└── README.mdTransport / logic split. client.py is a plain async HTTP client you can import from scripts or CLI tools without pulling the MCP runtime. server.py only owns the MCP tool surface.
Bearer-token auth. Cloudcraft's API expects Authorization: Bearer <key> (not Apikey). The client sets this automatically.
No secrets in process args. The API key is read from CLOUDCRAFT_API_KEY; never pass it on the command line.
One implementation. PyPI, npm, MCPB, and the container all launch the same versioned Python package rather than maintaining language-specific forks.
Error surface. Non-2xx responses raise CloudcraftError with status and body preserved, re-wrapped as RuntimeError at the MCP boundary so Claude sees a readable message.
API keys grant full read / write over your Cloudcraft account. Treat them as secrets and rotate regularly.
MCP tool annotations mark read-only tools and mutating/destructive tools so compatible hosts can present better approval prompts. These annotations are hints, not an enforcement layer.
Environment gates and exact-ID delete confirmation are defense in depth, not an interactive approval workflow; keep the MCP host's tool approval UX enabled.
Cloudcraft mutations are disabled by default. Set CLOUDCRAFT_ENABLE_WRITES=true
only for clients that need create/update access. Deletes additionally require
CLOUDCRAFT_ENABLE_DELETES=true and an exact repeated blueprint ID on every call.
delete_blueprint is irreversible — when asking Claude to delete, be explicit about the target id.
export_blueprint_image writes are sandboxed under CLOUDCRAFT_EXPORT_DIR
(a process-private temporary subdirectory by default) and refuse to overwrite
existing files unless overwrite=True.
For read-heavy setups, create a dedicated Cloudcraft user with read-only scope (if/when Cloudcraft adds scoped keys) and use that key for MCP.
Supported versions and private reporting instructions are in SECURITY.md; data flow is documented in PRIVACY.md.
Issues and PRs welcome at https://github.com/hypark5540/cloudcraft-mcp. Please run ruff, mypy, and pytest before submitting.
MIT — see LICENSE.
awslabs/mcp — AWS's collection of MCP servers
modelcontextprotocol/servers — reference MCP server implementations
Create a new Cloudcraft blueprint.
Args: name: Display name for the new blueprint. data: Full blueprint payload (nodes, edges, groups, surfaces, text, icons, connectors, theme, projection, etc.). See README for a minimal example.
Returns the created blueprint metadata including the assigned id.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| data | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states that the tool creates a blueprint and returns metadata with an assigned id. However, it doesn't disclose behavioral traits like idempotency, error conditions, or resource limits. Adequate for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: a one-line summary followed by a brief Args section and a note about return value. No fluff, but the Args section could be more structured. Still, it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 2 required parameters and an output schema, so description need not explain return values in detail. The description provides essential context: it creates a blueprint and returns metadata with id. The schema for 'data' is complex, but the description points to a README for examples, which is acceptable given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains the two parameters: 'name' is a display name, and 'data' is the full blueprint payload with a list of components. This adds meaning beyond the schema, which only provides titles. However, 'data' is described as a complex payload but details are deferred to a README, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new Cloudcraft blueprint' with a specific verb and resource. Distinguishes from siblings like 'update_blueprint' and 'delete_blueprint' by explicitly saying 'create' and 'new'. The sibling list includes other operations on blueprints, so this description makes it distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance, but the description implies it's for creating new blueprints. The sibling tools like 'update_blueprint' and 'delete_blueprint' provide alternatives, but no exclusions or prerequisites are mentioned. Adequate but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Cloudcraft blueprint. Irreversible — confirm before calling.
Args: blueprint_id: Blueprint UUID.
| Name | Required | Description | Default |
|---|---|---|---|
| blueprint_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully carries the burden of behavioral disclosure. It clearly states the destructive and irreversible nature of the tool, which is critical for an AI agent to understand before invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for purpose and a warning, plus a single parameter doc line. No unnecessary text, front-loaded with the critical irreversible warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (implied), the description is complete. It covers purpose, usage guidance, behavioral transparency, and parameter meaning. No gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'blueprint_id: Blueprint UUID', adding context that the parameter is a UUID. Given that schema description coverage is 0%, this helps clarify the parameter meaning beyond the schema, though it could provide more detail like format or example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'delete' on the 'blueprint' resource. It is unambiguous and distinct from sibling tools like 'create_blueprint' or 'update_blueprint'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns that the operation is irreversible and advises confirmation before calling. This provides clear guidance on when and how to use the tool, distinguishing it from non-destructive operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a Cloudcraft blueprint to an image file on disk.
Args:
blueprint_id: Blueprint UUID.
format: One of png, svg, pdf, mxgraph. Default png.
output_path: Absolute path to save to. Default: /tmp/cloudcraft_<id>.<ext>.
scale: Optional PNG render scale (e.g. 1.0, 2.0). PNG only.
transparent: PNG transparent background (bool). PNG only.
Returns:
{"path": <saved_path>, "bytes": <size>, "format": <fmt>}
| Name | Required | Description | Default |
|---|---|---|---|
| blueprint_id | Yes | ||
| format | No | png | |
| output_path | No | ||
| scale | No | ||
| transparent | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the parameters and return value well, but does not disclose side effects (e.g., file creation on disk, permission requirements, or any destructive behavior). The description is accurate and non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet-like Args and Returns sections, front-loading the core action. Every sentence provides essential information; no fluff. It's concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, 1 required, no enums, has output schema), the description covers the action, parameters, and return format adequately. It doesn't explain file overwrite behavior or disk space implications, but these are minor. The output schema exists but the description still explains return values, which is helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains each parameter's purpose, allowed values (format options), and constraints (scale/transparent for PNG only). The output_path default is specified. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a Cloudcraft blueprint to an image file on disk, specifying the verb 'render' and the resource 'blueprint image'. It distinguishes itself from siblings like get_blueprint (which likely returns JSON) and snapshot_aws (AWS snapshot).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides default values and allowed formats but does not explicitly state when to use this tool versus alternatives like get_blueprint or list_blueprints. The return format is described, but no guidance on prerequisites or when not to use is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full blueprint payload (nodes, edges, groups, layout).
Args:
blueprint_id: Blueprint UUID from :func:list_blueprints.
| Name | Required | Description | Default |
|---|---|---|---|
| blueprint_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the return payload components but doesn't mention read-only nature, performance implications, or any side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, with a one-line summary and clear Args section. No wasted words, though the docstring style is slightly more verbose than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema, the description is mostly complete. It covers purpose and parameter source. Could add return format details or pagination/limits, but output schema may cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description adds meaning for the one parameter (blueprint_id) by referencing list_blueprints to obtain it. However, it doesn't specify format or constraints beyond what the schema shows (string).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it fetches the full blueprint payload, listing components like nodes, edges, groups, and layout. This is clear and specific, but doesn't explicitly differentiate from siblings like list_blueprints which lists metadata only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a full blueprint is needed, but provides no when-not-to-use or alternative guidance. It references list_blueprints for obtaining the ID, which is helpful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List AWS accounts registered with Cloudcraft for live-scan snapshots.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the tool lists accounts, which is a read-only operation, but does not describe any behavioral traits like output format, pagination, or error conditions. A score of 3 is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, has an output schema, and is simple. The description is complete enough for its simplicity, though it could mention that the output schema provides details of the accounts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (no parameters), so there is nothing to add. The description correctly indicates the tool has no parameters, which is sufficient. Baseline 4 is appropriate given no param info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('AWS accounts registered with Cloudcraft'), and it distinguishes the tool from siblings by specifying the purpose ('for live-scan snapshots'). It clearly separates this from other tools like 'snapshot_aws' which triggers a snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (listing accounts for snapshots) but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Cloudcraft blueprint (diagram) in the authenticated account.
Returns a compact summary per blueprint (id, name, tags, updatedAt).
Use :func:get_blueprint afterwards to pull the full node / edge JSON.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool is a read operation returning a compact summary with specific fields (id, name, tags, updatedAt). This is adequate transparency for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema exists (handling return value explanation), the description is complete. It tells the agent what the tool does, what it returns, and how to proceed next.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (no parameters), so baseline is high. The description adds context by explaining what the output contains (compact summary) and the specific fields, which is helpful beyond an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('Cloudcraft blueprint (diagram)') and clarifies scope ('in the authenticated account'). It clearly distinguishes from siblings like 'get_blueprint' by noting this returns a summary, not full node/edge JSON.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states to use 'get_blueprint' afterwards for full details, providing clear guidance on the tool's role in a workflow. However, it does not mention when not to use it or any alternative among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a live-scan snapshot of one AWS service via Cloudcraft.
Args:
account_id: Cloudcraft AWS account id (from :func:list_aws_accounts).
region: AWS region code, e.g. ap-northeast-2.
service: Service to snapshot, e.g. ec2, s3, rds, lambda, vpc.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | ||
| region | Yes | ||
| service | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'live-scan' implying real-time data retrieval, but does not disclose potential side effects, permissions, rate limits, or whether it modifies state. Annotations would have helped, but the description adds some context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-sentence summary followed by parameter explanations in a standard docstring format. No unnecessary words, but could be slightly more structured (e.g., bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, but has output schema), the description adequately explains the tool's purpose and parameters. It references a sibling tool (list_aws_accounts) for account_id, which helps. The output schema exists, so return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), so the description must compensate. It explains each parameter: account_id (from list_aws_accounts), region (with example), and service (with examples). This adds significant meaning beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it takes a 'live-scan snapshot' of an AWS service via Cloudcraft, specifying the exact action (snapshot) and resource (AWS service). This distinguishes it from sibling tools like create_blueprint or export_blueprint_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates this is for scanning live AWS services, and the mention of list_aws_accounts for getting account_id provides cross-reference. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the full data payload of an existing blueprint.
Args:
blueprint_id: Blueprint UUID.
data: Full blueprint payload (same shape as :func:create_blueprint).
| Name | Required | Description | Default |
|---|---|---|---|
| blueprint_id | Yes | ||
| data | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the update replaces the full payload (destructive overwrite), which is critical. However, it doesn't mention idempotency, version conflicts, or whether existing fields not included in data are cleared, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action, and includes a concise bullet list for parameters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema (nested objects) and no annotations, the description provides essential behavioral context (full replacement) and references the creation schema for data shape. An output schema exists, so return values aren't needed. Minor gap: no mention of versioning or conflict handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by stating 'data' must be the full blueprint payload with the same shape as create_blueprint, which the schema alone doesn't clarify. Schema description coverage is 0%, so the description compensates. However, the blueprint_id parameter is minimally described as 'Blueprint UUID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it replaces the full data payload of an existing blueprint, using specific verbs and resources ('Replace the full data payload of an existing blueprint'). This distinguishes it from siblings like create_blueprint (creates new) and delete_blueprint (deletes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for updating an existing blueprint, contrasting with create_blueprint for new ones. It notes the 'data' parameter must have the same shape as create_blueprint, guiding reuse of the creation schema. However, no explicit when-not-to-use or alternative suggestions for partial updates are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Cloudcraft user profile for the current API key.
Useful as a sanity check after configuring a new key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description indicates a read-only operation returning profile info. It does not mention side effects, but with zero parameters and output schema, the behavior is well-understood. The description is clear enough for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no fluff. The first sentence states purpose, the second provides usage context. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description is complete. It explains what the tool does and when to use it. No missing information for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameters and 100% coverage, so description need not add parameter info. It correctly omits parameter details since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns the user profile for the current API key. The verb 'return' and resource 'user profile' are specific. However, it does not differentiate from siblings since no other tool returns user info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's useful as a sanity check after configuring a new key, providing clear context for when to use it. No alternatives or exclusions are mentioned, but given no other sibling does this, it's sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0create_blueprintdelete_blueprintexport_blueprint_imageget_blueprintlist_aws_accountslist_blueprintssnapshot_awsupdate_blueprintwhoamiEach tool targets a distinct resource or action: blueprints (CRUD + export), AWS accounts (list), snapshot (live-scan), and user profile (whoami). There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (e.g., create_blueprint, list_aws_accounts, snapshot_aws), making them predictable and easy to understand.
9 tools is well-scoped for a diagramming and cloud infrastructure server. Each tool serves a clear purpose without redundancy or excess.
The tool set covers full CRUD for blueprints, plus export, AWS account listing, snapshot, and user info. Minor gaps include the lack of an update operation for AWS accounts or snapshot management, but core workflows are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI Visibility and Content Intelligence tools for Claude and MCP-compatible agents.
Connect Amazon Seller Central to Claude or ChatGPT via MCP. Orders, inventory, pricing, fees, FBA.
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
Connect Claude AI to UluP Spaces via MCP — create projects, nodes, and tasks with OAuth 2.0.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hypark5540/cloudcraft-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
