Skip to main content
Glama
FreddieWho

AI Galaxy Compute MCP

by FreddieWho
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

AI Galaxy Compute MCP

智星云（AI Galaxy）OpenAPI v2 的安全封装，提供 CLI 和 stdio MCP 两种使用方式，供 Codex 或其他自动化 agent 在预算与安全边界内完成算力发现、询价、租用、连接和退租。

目标不是无约束消费，而是提供“实时发现 → 询价 → 预算校验 → 显式创建 → 接入 → 退租 → 磁盘清理”的受控自动化闭环。

特性

  • 仅依赖 Python 标准库 + mcp，无需额外运行时。

  • CLI 入口：ai-galaxy-compute

  • MCP 入口：ai-galaxy-compute-mcp（stdio）

  • 支持 CPU 与 GPU 实例筛选、实时询价、创建前预算校验。

  • 内置性价比评估：按"稠密 FP16 TFLOPS / 元每小时"对可租 GPU 排序，签约前先行比价。

  • 支持实例原地升配（CPU/内存）、添加数据盘、调整带宽、重启、重置系统盘、续费。

  • 支持"保留磁盘启动"：CPU 实例配环境 → 退租保留磁盘 → 按需启动 GPU/CPU 实例。

  • 租用/退租为两阶段操作，必须显式确认，且使用一次性 HMAC 审批令牌。

  • 默认不返回初始化密码、VNC/SSH 临时密码等敏感字段。

  • 所有远程写操作不自动重试，避免网络抖动导致重复下单。

  • 自动续费固定关闭；对时长、总价、小时价、GPU 数、磁盘、带宽均设有策略上限。

Related MCP server: clausius

安全模型

  1. 凭据来源

    • 环境变量 AI_GALAXY_ACCESS_KEY / AI_GALAXY_SECRET_KEY；或

    • 权限为 0600 的本地 JSON 文件，路径通过 AI_GALAXY_CREDENTIALS_FILE 指定。

    • 不要把凭据写入 .env、计划文件、shell history 或提交到 Git。

  2. 默认只读

    • auth、catalog、balance、instances、status、connect 不会创建或修改资源。

    • plan / plan_release 只询价，不下单。

  3. 写操作两阶段

    • plan → 生成私有 approval_token。

    • rent 必须传入与计划文件完全匹配的 approval_token，且受预算上限保护。

    • 令牌由本机 0600 随机密钥用 HMAC 签发，计划文件被修改后立即失效。

    • 令牌消费记录持久化；创建请求超时后禁止复用，必须先 instances 对账。

  4. 敏感信息脱敏

    • connect 默认只返回 host、端口、用户名；只有 --include-sensitive 才返回密码。

安装

git clone <repo-url>
cd ai-galaxy-compute
python -m venv .venv
source .venv/bin/activate
python -m pip install -e .

依赖：Python >= 3.10，mcp>=1.28,<2。

配置凭据

推荐方式（MCP 必须使用此方式）：

mkdir -p ~/.config/ai-galaxy-compute
install -m 600 /dev/null ~/.config/ai-galaxy-compute/credentials.json

编辑文件，写入：

{
  "access_key": "你的 AccessKey",
  "secret_key": "你的 SecretKey"
}

确认权限：

chmod 600 ~/.config/ai-galaxy-compute/credentials.json
export AI_GALAXY_CREDENTIALS_FILE="$HOME/.config/ai-galaxy-compute/credentials.json"

也可以临时使用环境变量（仅 CLI）：

export AI_GALAXY_ACCESS_KEY='...'
export AI_GALAXY_SECRET_KEY='...'

注意：通过 shell 输入会进入 history，生产环境建议使用凭据文件。

CLI 使用

只读检查

ai-galaxy-compute auth
ai-galaxy-compute balance
ai-galaxy-compute catalog
ai-galaxy-compute instances

筛选并询价（不会创建实例）

先跑性价比评估（只读，不创建），选出 gpu_type 与卡数：

ai-galaxy-compute evaluate --gpu-count 1 --min-cpu 4 --min-memory 16

输出按 tflops_per_yuan（稠密 FP16 TFLOPS / 元每小时）降序排列，含每档的规格、单价、显存；未识别型号的 GPU 列在最后（tflops_per_yuan=null），并附纯 CPU 最低价选项与平台带宽/磁盘单价。然后用评估结果询价：

ai-galaxy-compute plan \
  --gpu-type 'GeForce RTX 4090' \
  --gpu-count 1 \
  --image ubuntu22_cuda12 \
  --hours 1 \
  --min-cpu 4 \
  --min-memory 16 \
  --max-hourly-price 2 \
  --max-total-price 2 > rental.plan.json

确认后租用

检查 rental.plan.json，复制其中的 approval_token：

ai-galaxy-compute rent \
  --plan-file rental.plan.json \
  --approval-token '<token>' \
  --max-total-price 2

查询与连接

ai-galaxy-compute status '<instance_name>'
ai-galaxy-compute connect '<instance_name>' --wait-seconds 600

退租

ai-galaxy-compute release-plan '<instance_name>' > release.preview.json
ai-galaxy-compute release \
  --preview-file release.preview.json \
  --approval-token '<token>'

平台提前退租不会自动释放保留磁盘；如果实例进入状态 8，仍需另行调用保留磁盘释放接口。当前版本不会声称状态 8 已完成清理。

实例规格升级（CPU/内存，原地升配）

ai-galaxy-compute resize-options '<instance_name>'            # 查看可升级规格
ai-galaxy-compute resize-plan '<instance_name>' \
  --new-spec ecs.c4.base --max-total-price 1 > resize.preview.json
ai-galaxy-compute resize \
  --preview-file resize.preview.json \
  --approval-token '<token>' --max-total-price 1

只能升级 CPU/内存，不可降配，也不能原地变更 GPU 数量；变更 GPU 请走"保留磁盘启动"。

添加数据盘

ai-galaxy-compute disk-plan '<instance_name>' --add-gb 20 --max-total-price 1 > disk.preview.json
ai-galaxy-compute disk-add --preview-file disk.preview.json --approval-token '<token>' --max-total-price 1

磁盘只能增加（单次最小 10GB，最多 16 块），系统盘不可变更。

调整网络带宽

ai-galaxy-compute bandwidth-plan '<instance_name>' --bandwidth 64 \
  --max-total-price 1 --max-bandwidth 128 > bandwidth.preview.json
ai-galaxy-compute bandwidth \
  --preview-file bandwidth.preview.json --approval-token '<token>' \
  --max-total-price 1 --max-bandwidth 128

0～32Mbps 免费；超出部分按单价每小时定时扣费。带宽上限 MaxBandwidth 由实例列表接口返回。

保留磁盘启动新实例（CPU 配环境 → GPU 干活）

实例到期或退租后若磁盘被保留（状态 8），可以用原磁盘按任意规格启动新实例：

ai-galaxy-compute boot-plan '<原 instance_name>' \
  --gpu-type 'GeForce RTX 4090' --gpu-count 1 --hours 2 \
  --max-hourly-price 2 --max-total-price 4 > boot.plan.json
ai-galaxy-compute boot --plan-file boot.plan.json --approval-token '<token>' --max-total-price 4

典型工作流：

  1. 用 --gpu-type CPU --gpu-count 0 租一台便宜的纯 CPU 实例（--due-mode 1，到期保留磁盘）。

  2. 在 CPU 实例上装好环境（无需为 GPU 空转付费）。

  3. 退租 CPU 实例，磁盘保留（状态 8）。

  4. 用 boot-plan / boot 从保留磁盘启动 GPU 实例开始训练。

  5. 结束后再次退租保留磁盘，之后还能切回 CPU 规格继续维护环境。

重启 / 重置系统 / 到期策略

ai-galaxy-compute restart '<instance_name>'                       # 运行中重启
ai-galaxy-compute restart '<instance_name>' --from-shutdown       # 在系统内关机后启动
ai-galaxy-compute local-images '<instance_name>'                  # 查看可重置的镜像
ai-galaxy-compute reinit '<instance_name>' --image ubuntu22_cuda12  # 重置系统盘（数据盘保留）
ai-galaxy-compute due-mode '<instance_name>' --due-mode 1         # 1 到期保留磁盘，-1 到期释放

KVM 实例没有"关机"接口：需要停止时在系统内部执行 shutdown，之后用 --from-shutdown 启动。

续费、备注与费用查询

ai-galaxy-compute renew-plan '<instance_name>' --hours 4 --max-total-price 8 > renew.preview.json
ai-galaxy-compute renew --preview-file renew.preview.json --approval-token '<token>' --max-total-price 8
ai-galaxy-compute note '<instance_name>' --note 'env-setup cpu node'
ai-galaxy-compute costs                            # 账户实例状态统计
ai-galaxy-compute costs '<instance_name>'          # 单实例费用汇总与明细

保留盘巡检与清理

保留磁盘（状态 8）按小时计费，退租后必须显式清理：

ai-galaxy-compute kept-disks                       # 列出所有保留中的磁盘及累计费用
ai-galaxy-compute cleanup-kept-disk '<instance_name>'   # 永久释放保留磁盘

建议每次会话开始/结束都跑一次 kept-disks：非空结果就是在空烧钱。 release 退租后若实例进入状态 8，输出中会带 warning 字段提示。

MCP 注册

codex mcp add aiGalaxyCompute \
  --env AI_GALAXY_CREDENTIALS_FILE=$HOME/.config/ai-galaxy-compute/credentials.json \
  --env AI_GALAXY_STATE_DIR=$HOME/.local/state/ai-galaxy-compute \
  -- $HOME/.local/bin/ai-galaxy-compute-mcp

提供的工具：

工具

作用

catalog

实时 CPU/GPU 规格、库存和价格；inventory_counts 是平台库存，quote_candidate_counts 是本地规格预检候选，missing_enabled_spec_counts 显示两者不一致；旧字段 rentable_counts 保持为候选列表

evaluate

性价比排序（FP16 TFLOPS/元每小时），签约前比价，只读；未进入报价计算的库存组合见 unevaluated_inventory

balance

账户余额与额度

costs

费用查询：实例状态统计、单实例费用汇总与明细，只读

plan_rental

选择并询价，返回 plan_id，不创建实例

rent

消费一次性内部计划并创建实例，必须 confirm=true

get_instance

等待运行并返回脱敏连接信息

plan_release

为本 MCP 创建的实例生成退租询价

release

消费退租计划，必须 confirm=true

cleanup_kept_disk

永久释放保留磁盘，必须 confirm=true

local_images

查询实例可用于重置系统的镜像

resize_options

查询实例可升级的规格（CPU/内存）

plan_resize

升配询价，返回 plan_id，不改动实例

resize

消费升配计划执行原地升级，必须 confirm=true

plan_disk_add

添加数据盘询价，不改动实例

disk_add

消费加盘计划，必须 confirm=true

plan_bandwidth

带宽调整询价（0~32Mbps 免费），不改动实例

set_bandwidth

消费带宽计划执行调整，必须 confirm=true

plan_kept_boot

从保留磁盘启动新实例询价（可换 GPU 数量或纯 CPU），不创建

kept_boot

消费保留盘启动计划并创建实例，必须 confirm=true

restart_instance

重启实例；from_shutdown=true 用于系统内关机后的启动

reinit_instance

重置系统盘为新镜像（数据盘保留），必须 confirm=true

set_due_mode

设置到期处理：1 保留磁盘，-1 到期释放，必须 confirm=true

plan_renew

续费询价，不扣费

renew

消费续费计划，必须 confirm=true

set_note

设置实例备注（≤25 字），用于标记用途

kept_disks

巡检保留中的磁盘（状态 8）及累计费用，会话开始/结束时必查

plan_rental 默认 kind="cheapest" 且不传 GPU 参数时选择 CPU；GPU 询价必须显式传 kind="gpu"、gpu_type 和正数 gpu_count。冲突参数会直接失败， 不会被静默改写成 CPU 计划。缺少启用规格的库存组合只会进入诊断字段，不会被伪装成可下单。

测试

单元测试不使用真实凭据、不访问网络、不产生费用：

PYTHONPATH=src python -m unittest discover -s tests -v

线上测试建议按 auth -> catalog -> instances -> plan 顺序进行；除非明确决定产生费用，不运行 rent。

项目结构

src/ai_galaxy_compute/
├── client.py      # 签名 HTTP 客户端和 OpenAPI 端点
├── broker.py      # 规格选择、性价比评估、预算策略、询价、租用、变更
├── gpu_perf.py    # GPU 性能对照表（近似公开参数，用于性价比排序）
├── cli.py         # 命令行入口
├── mcp_server.py  # FastMCP 工具定义
├── plan_store.py  # 私有计划、文件锁、ownership 和状态迁移
├── ledger.py      # HMAC 审批令牌与一次性消费记录
├── signing.py     # 请求签名
├── transport.py   # multipart/form-data HTTP 传输
└── errors.py      # 异常类型

tests/             # 单元测试

接口依据

License

MIT

AutoDL MCP

同一发行包还提供独立的 AutoDL 容器实例 Pro API MCP：

autodl-compute catalog
autodl-compute-mcp

配置、工具边界和凭据说明见 docs/AUTODL_MCP.md。AutoDL 当前未提供文档化的创建前报价接口，因此该 MCP 将租用标记为 UNQUOTED，必须显式确认后才能创建。

Available Tools

8 tools
balanceA
Read-only

Read-only account balance and credit summary.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'Read-only' aligns. It adds context about returning 'account balance and credit summary', which enhances understanding beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with 'Read-only', and contains no filler. Every word adds value, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and the presence of an output schema, the description fully covers what the tool does. It is complete for its simplicity, needing no further explanation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters (0 params), and schema coverage is 100% trivially. The description adds no parameter info, which is acceptable; baseline for 0 parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Read-only account balance and credit summary' uses a specific verb ('read-only') and resource ('account balance and credit summary'), clearly distinguishing it from sibling tools like 'catalog' or 'get_instance' by focusing on financial account information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states what the tool does but provides no explicit guidance on when to use it versus alternatives or when not to use it. The read-only nature is implied, but no exclusions or context are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

catalogA
Read-only

List compact current CPU specs and GPU offers; no billable action.

ParametersJSON Schema
NameRequiredDescriptionDefault
only_availableNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and non-destructive behavior. The description adds that the tool lists compact, current data and explicitly states no billable action, providing context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose and a key behavioral trait.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the output schema exists and the main purpose is clear, the description fails to cover the 'only_available' parameter, which is essential for proper use. The usage context relative to siblings is also not fully addressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the 'only_available' parameter (boolean with default true). The parameter's purpose is not clarified, leaving the agent without guidance on filtering behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists compact current CPU specs and GPU offers, with no billable action. It uses a specific verb ('List') and resource ('CPU specs and GPU offers'), distinguishing it from sibling billing tools like 'rent' or 'release'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for informational checks without billing, but does not explicitly state when to use this tool versus siblings like 'balance' or 'plan_rental'. No alternatives or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cleanup_kept_diskB
Destructive

Permanently release any retained disk for an MCP-created instance.

ParametersJSON Schema
NameRequiredDescriptionDefault
confirmYes
instance_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true and readOnlyHint=false; the description adds that the release is 'permanent' and scoped to 'MCP-created instances'. However, it does not elaborate on what 'retained disk' means or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no redundant words, making it concise. It is front-loaded with the key action, though extremely brief.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with a confirmation parameter and an output schema, the description lacks necessary context such as the irrevocability of the action, the role of 'confirm', or any error conditions. It is not complete enough for safe usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must explain the parameters but completely omits their meaning. The two required parameters (instance_name, confirm) are not described, leaving the agent without clarity on their purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (release retained disk) and the specific context (MCP-created instance), effectively distinguishing it from sibling tools like 'release' and 'rent' which target different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, warnings, or exclusion criteria, despite the destructive nature and the need for confirmation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_instanceA
Read-only

Get redacted instance/connection status, optionally waiting until running.

ParametersJSON Schema
NameRequiredDescriptionDefault
wait_secondsNo
instance_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by disclosing the waiting behavior and that the status is 'redacted,' which are important behavioral traits beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that captures the core functionality without extraneous words. Every phrase is meaningful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the output schema exists (reducing need to describe return values), the description lacks explanation of the 'redacted' nature and when waiting is beneficial. For a simple two-parameter tool, it is minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It only hints at wait_seconds via 'optionally waiting' but provides no details on instance_name or valid values for wait_seconds, leaving significant gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves instance/connection status with optional waiting, using a specific verb+resource structure. It distinguishes from sibling tools which have unrelated names like 'balance' or 'catalog'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not specify prerequisites, when waiting is appropriate, or when other sibling tools might be preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

plan_releaseA

Quote release for an instance created by this MCP; does not release.

ParametersJSON Schema
NameRequiredDescriptionDefault
instance_nameYes
quote_ttl_secondsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds value beyond annotations by clarifying that the operation is a quote and not an actual release, which aligns with the destructiveHint=false annotation. However, it does not address other behavioral aspects like authorization or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence) and front-loaded with the key action. However, it sacrifices essential parameter detail, reducing its overall effectiveness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low schema coverage and existence of an output schema (not shown), the description is too sparse. It does not explain what the quote entails, the role of the TTL parameter, or the expected output, leaving significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description should explain parameters. It implies 'instance_name' is the target instance but does not mention 'quote_ttl_seconds' at all, leaving its purpose unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'quotes' a release for an instance, and explicitly says it does not actually release, distinguishing it from the sibling 'release' tool. The verb and resource are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the description implies this tool is for obtaining a quote without releasing, it does not provide explicit guidance on when to use it versus alternatives like 'release', nor does it state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

plan_rentalB

Select and quote compute, storing a private signed plan; never creates.

ParametersJSON Schema
NameRequiredDescriptionDefault
kindNocheapest
min_cpuNo
gpu_typeNo
gpu_countNo
image_nameNoubuntu22_cuda12.4
min_memory_gbNo
duration_hoursNo
max_total_priceNo
max_hourly_priceNo
quote_ttl_secondsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds that it stores a signed plan, which is non-destructive but not read-only. It does not explain the lifecycle of the stored plan or return format, though an output schema exists. Moderate additional context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that is front-loaded with the core action. However, it sacrifices detail for brevity, making it less informative than it could be. Every word earns its place, but the balance is slightly off.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, 0% schema coverage, multiple siblings, and an output schema), the description is insufficient. It does not explain the output (signed plan), how parameters interact, or how it relates to siblings like 'catalog' or 'rent'. The agent would need additional knowledge to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for 10 parameters. The description does not explain any parameter semantics beyond the schema's titles and defaults. It fails to compensate for the lack of parameter documentation, leaving the agent without guidance on how to set values like 'kind', 'min_cpu', 'gpu_type', etc.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it selects and quotes compute, storing a private signed plan, and explicitly notes 'never creates,' which distinguishes it from sibling tools like 'rent' and 'release'. The verb+resource pair 'Select and quote compute' is specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for obtaining a quote before renting ('never creates'), but does not explicitly mention when to use versus alternatives like 'catalog' (for listing options) or 'rent' (for actual rental). No when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

releaseA
Destructive

Release an MCP-owned instance. Destructive; confirm must be true.

ParametersJSON Schema
NameRequiredDescriptionDefault
confirmYes
release_plan_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds the explicit behavior that confirm must be true, which is a key constraint not fully captured by schema alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—two sentences that quickly state the purpose and a critical usage condition. Every part is essential and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is minimal but covers the destructive nature and a required condition. However, it lacks explanation of the release_plan_id parameter and any context about the return value or prerequisites, leaving some gaps for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description should compensate but provides no details about the parameters. It only mentions that confirm must be true, but does not explain release_plan_id's purpose or format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Release') and the target ('an MCP-owned instance'), effectively distinguishing it from siblings like plan_release and rent. It is specific and direct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description warns that the tool is destructive and requires confirm to be true, which provides a condition for proper use. However, it does not explicitly state when to use this tool versus planning or other alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rentB
Destructive

Create exactly one instance from a stored plan. Billable; confirm must be true.

ParametersJSON Schema
NameRequiredDescriptionDefault
confirmYes
plan_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false. The description adds that 'confirm must be true' and that it is billable, but does not explain the destructive behavior or what resources are affected. The 'create' wording does not contradict annotations, as creation could involve destructive side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two short sentences that immediately convey the core action and key constraint. Every word adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is too brief for a creation tool with required parameters and an output schema. It fails to mention what the tool returns, prerequisites (e.g., plan must exist), or any side effects. The output schema exists but is not referenced.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, meaning the description must compensate. It only adds that 'confirm must be true', providing a constraint on the confirm parameter. The plan_id parameter receives no explanation, leaving its purpose ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an instance from a stored plan and mentions it is billable. However, it does not distinguish itself from sibling tools like 'plan_rental' or 'release', which could cause confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creating a rental instance but provides no guidance on when not to use it or how it differs from alternatives such as 'plan_rental' or 'release'. No exclusions or context for choosing this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 8 tool updatesv0.1.0
    • First observedbalance
    • First observedcatalog
    • First observedcleanup_kept_disk
    • First observedget_instance
    • First observedplan_release
    • First observedplan_rental
    • First observedrelease
    • First observedrent
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Scored across 8 tools

Disambiguation5/5

Each tool addresses a distinct operation: read-only queries (balance, catalog), planning (plan_rental, plan_release), lifecycle (rent, release, get_instance), and disk cleanup (cleanup_kept_disk). No two tools overlap in purpose.

Naming Consistency3/5

Tools mix naming conventions: some are single words (balance, catalog, release, rent) while others use verb_noun (cleanup_kept_disk, get_instance, plan_release, plan_rental). The pattern is not uniform, causing some inconsistency.

Tool Count5/5

With 8 tools, the set covers account info, catalog browsing, instance planning, creation, status, deletion, and disk cleanup. The number is appropriate for the domain without feeling sparse or bloated.

Completeness3/5

The set covers core instance lifecycle and billing but lacks a way to list all instances (only get_instance for a specific one) and no update operations. This leaves some gaps for workflow automation, though not severe.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • clausius

    tamohannes
    F
    license
    Not graded
    quality
    A
    maintenance
    An MCP server for monitoring and managing multi-cluster Slurm GPU jobs, enabling AI agents to execute commands, check allocations, and explore logs across HPC clusters.
    1
    -

  • AgentVault

    bch1212
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server for AI-native credential management, enabling agents to securely store, retrieve, and manage API keys with encryption, spending budgets, and audit logging.
    MIT

  • gpusmarket

    jyswee
    A
    license
    Not graded
    quality
    B
    maintenance
    MCP server for renting real GPUs from the terminal. Enables browsing, renting, chatting, managing, and pooling GPU instances with per-second billing, designed for AI agents.
    387
    1
    -