Skip to main content
Glama
Sign In

The Deployer

by com.thedploy
OverviewDiscussionsAdmin

Deployment progress and failure guidance

deployment
Read-onlyIdempotent

Where a deployment is (every step), what it waits on (a health-check proposal or a manual step), and for a failed one: the kind of failure, what to do about it, and the last error lines. Defaults to the project's latest deployment. Changes nothing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "deployment"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectNoThe project's id, name or repository. Optional with one project.
workspaceNoA teammate's workspace id. Default: your own.
wait_secondsNoSeconds to wait for the status or step to change
deployment_idNoA specific deployment, instead of the latest

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / wait_seconds / description
      Previous value: -"Wait up to this long for the status or step to change (no poll loop needed)"New value: +"Seconds to wait for the status or step to change"
    • changedInput schema / properties / workspace / description
      Previous value: -"Act in a teammate's workspace: its id from account. Default: your own."New value: +"A teammate's workspace id. Default: your own."
  2. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so 'Changes nothing' earns no extra credit. What does add value is disclosure of return content (per-step progress, blocking reason, failure kind, remediation hint, last error lines) and the waiting behavior of wait_seconds, none of which the annotations convey.

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?

One dense sentence that front-loads the primary question ('where a deployment is') and appends the failure case. No filler, and the negative capability ('Changes nothing') is placed last as a safety tag rather than buried.

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?

With no output schema, the description correctly spends its budget describing return content, which is exactly what an agent needs before calling. Minor gap: no mention of what happens when wait_seconds expires without a change, which matters for a polling tool.

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 baseline is 3. The description pushes above it by explaining the default resolution path ('Defaults to the project's latest deployment') and framing what a wait is waiting on, which the schema's 'Seconds to wait for the status or step to change' only partially covers.

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?

States a specific resource and what is returned: deployment position (every step), blocking condition (health-check proposal or manual step), and failure detail. That is far more concrete than a name restatement. It stops short of explicitly distinguishing itself from siblings like status, logs, or diagnose, so an agent must infer the boundary.

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?

Usage is implied ('for a failed one: the kind of failure, what to do about it') rather than stated with a when/when-not rule. The default-to-latest behavior is helpful context for choosing it without a deployment_id. No alternative tool is named, even though diagnose and logs are obvious candidates to route away from.

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

All The Deployer toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources