Skip to main content
Glama
GeiserX

cashpilot-mcp

by GeiserX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

Deploy service

deploy_service
Destructive

Deploy a catalog service to a worker by pulling its image and starting containers; redeploy to apply new settings, with omitted env keys retaining saved values.

Instructions

Deploy a catalog service on one worker: CashPilot pulls the image and starts its container(s). Deploying a service that already runs there redeploys it with the new settings; keys left out of env keep their saved values. The env keys a service needs (account email, token, ...) are listed in list_available_services. Can take a few minutes.

Input Schema

NameRequiredDescriptionDefault
envNoEnvironment variables for the container, as string values, e.g. {"EMAIL":"me@example.com","PASSWORD":"..."}.
slugYesService to deploy. Lowercase catalog slug, e.g. "honeygain"; list_deployed_services and list_available_services show them.
hostnameNoDevice name the provider shows for this node. Default: CashPilot's own.
instancesNoCopies to run on this worker, 1 to 10. Many providers allow one per IP; CashPilot refuses more where that is the case. Default: keep the current number, 1 for a new deployment.
worker_idNoWorker (server) to act on, from list_workers. Required when more than one worker is online; with a single online worker CashPilot picks it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.3.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / env / additionalProperties
      Added value: +{
+  "type": "string"
+}
    • changedInput schema / properties / env / description
      Previous value: -"Optional JSON string of environment variable key-value pairs"New value: +"Environment variables for the container, as string values, e.g. {\"EMAIL\":\"me@example.com\",\"PASSWORD\":\"...\"}."
    • addedInput schema / properties / env / properties
      Added value: +{}
    • changedInput schema / properties / env / type
      Previous value: -"string"New value: +"object"
    • addedInput schema / properties / hostname
      Added value: +{
+  "description": "Device name the provider shows for this node. Default: CashPilot's own.",
+  "maxLength": 63,
+  "type": "string"
+}
    • addedInput schema / properties / instances
      Added value: +{
+  "description": "Copies to run on this worker, 1 to 10. Many providers allow one per IP; CashPilot refuses more where that is the case. Default: keep the current number, 1 for a new deployment.",
+  "maximum": 10,
+  "minimum": 1,
+  "type": "integer"
+}
    • changedInput schema / properties / slug / description
      Previous value: -"Service slug to deploy"New value: +"Service to deploy. Lowercase catalog slug, e.g. \"honeygain\"; list_deployed_services and list_available_services show them."
    • addedInput schema / properties / slug / pattern
      Added value: +"^[a-z0-9][a-z0-9._-]{0,63}$"
    • addedInput schema / properties / worker_id
      Added value: +{
+  "description": "Worker (server) to act on, from list_workers. Required when more than one worker is online; with a single online worker CashPilot picks it.",
+  "minimum": 1,
+  "type": "integer"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds meaningful behavior: it pulls the image, starts containers, redeploys existing services with new settings, merges env values, and can take several minutes. It does not discuss permissions or exact failure behavior, but it adds substantial 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 four tightly written sentences with no filler. It front-loads the core action and then adds redeploy semantics, env guidance, and runtime expectations in a logical order.

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

Completeness4/5

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

For a destructive, non-idempotent deployment tool with full schema coverage and rich annotations, the description covers the essential operational behavior, including redeploy and env merge semantics plus duration. It does not describe the return value, but no output schema exists and the core invocation context is otherwise complete.

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?

Schema coverage is 100%, so the schema already documents all five parameters. The description still adds useful semantics by explaining that omitted env keys keep saved values and that required env keys are listed in list_available_services.

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 states a specific verb and resource: deploy a catalog service on one worker. It also clarifies that CashPilot pulls the image and starts containers, which distinguishes deployment from sibling operations like start_service or restart_service.

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 gives clear usage context: deploying an already-running service redeploys it with new settings, and omitted env keys preserve saved values. It does not explicitly say when to use start_service or restart_service instead, so it falls short of full alternative routing.

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

Deploy Server

Other Tools