Cloudcraft.co 的模型上下文协议 (MCP) 服务器 — 可从 Claude Desktop 和其他 MCP 客户端列出、读取、导出和构建云架构蓝图。
向 MCP 主机公开了九个工具：
工具 | 描述 |
| 返回已配置密钥的 Cloudcraft 用户资料。 |
| 列出账户中的所有蓝图。 |
| 获取蓝图的完整节点/边 JSON。 |
| 从 JSON 有效负载创建新蓝图。 |
| 替换现有蓝图的有效负载。 |
| 删除蓝图（不可逆）。 |
| 将蓝图渲染为磁盘上的 PNG / SVG / PDF / mxgraph。 |
| 列出用于实时扫描快照的已连接 AWS 账户。 |
| 对一个 AWS 服务进行实时扫描快照。 |
Related MCP server: AWS MCP Server
Python 3.10+
uv (brew install uv)
Cloudcraft API 密钥 — 在 https://app.cloudcraft.co/ → 用户设置 → API 密钥处生成
克隆仓库并让 uv 在首次运行时解析依赖项 — 无需显式安装步骤。
git clone https://github.com/hypark5540/cloudcraft-mcp.git
cd cloudcraft-mcp
export CLOUDCRAFT_API_KEY='your-key-here'
uv run cloudcraft-mcp # smoke test — Ctrl+C to exit编辑 ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 或您平台上的等效文件：
{
"mcpServers": {
"cloudcraft": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/cloudcraft-mcp",
"run",
"cloudcraft-mcp"
],
"env": {
"CLOUDCRAFT_API_KEY": "your-key-here"
}
}
}
}重启 Claude Desktop。开发者选项卡应显示 cloudcraft 已连接。
名称 | 必需 | 默认 | 用途 |
| 是 | — | API 密钥 (Bearer)。在 Cloudcraft 用户设置中生成。 |
| 否 |
| 用于代理或未来 API 版本的覆盖。 |
| 否 |
| Stderr 日志详细程度 ( |
服务器连接后，您可以询问 Claude 诸如：
“列出我的 Cloudcraft 蓝图并总结每个蓝图代表的内容。”
“将蓝图
f0086b32-...导出为 PNG 并保存到我的桌面。”
“使用我刚刚设计的架构创建一个名为 'Prod 2026' 的新 Cloudcraft 蓝图。”
“为我已连接的 AWS 账户对
ap-northeast-2中的 EC2 实例进行快照。”
create_blueprint / update_blueprint 接受完整的 Cloudcraft data 对象。一个最小的有效负载：
{
"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
}有关完整的节点类型目录和服务特定字段，请参阅 Cloudcraft 的 API 文档。
uv sync --extra dev
uv run pytest # unit tests (no network)
uv run ruff check . # lint
uv run mypy src # type check测试使用 respx 模拟 HTTP 层，因此不需要 API 密钥。
cloudcraft-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
├── server.py # back-compat shim -> cloudcraft_mcp.server:main
├── pyproject.toml
├── LICENSE
└── README.md传输/逻辑分离。 client.py 是一个简单的异步 HTTP 客户端，您可以在脚本或 CLI 工具中导入它，而无需引入 MCP 运行时。server.py 仅负责 MCP 工具接口。
Bearer 令牌认证。 Cloudcraft 的 API 需要 Authorization: Bearer <key> (而不是 Apikey)。客户端会自动设置此项。
进程参数中无密钥。 API 密钥从 CLOUDCRAFT_API_KEY 读取；切勿在命令行上传递它。
错误处理。 非 2xx 响应会引发保留状态和主体的 CloudcraftError，并在 MCP 边界处重新包装为 RuntimeError，以便 Claude 能看到可读的消息。
API 密钥授予对您 Cloudcraft 账户的完全读/写权限。请将其视为机密并定期轮换。
delete_blueprint 是不可逆的 — 当要求 Claude 删除时，请明确指定目标 ID。
对于读取密集型设置，请创建一个具有只读范围的专用 Cloudcraft 用户（如果/当 Cloudcraft 添加范围密钥时），并将该密钥用于 MCP。
欢迎在 https://github.com/hypark5540/cloudcraft-mcp 提交问题和 PR。提交前请运行 ruff、mypy 和 pytest。
MIT — 参见 LICENSE。
awslabs/mcp — AWS 的 MCP 服务器集合
modelcontextprotocol/servers — 参考 MCP 服务器实现
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.
v0.1.0create_blueprintdelete_blueprintexport_blueprint_imageget_blueprintlist_aws_accountslist_blueprintssnapshot_awsupdate_blueprintwhoamiScored across 9 tools
Each 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.
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.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
