Skip to main content
Glama
Sign In

The Deployer

by com.thedploy
OverviewDiscussionsAdmin

Check a repository

check_repo
Read-only

Checks whether a public GitHub, GitLab or Bitbucket repository will deploy: the services it found, what's missing (each with its fix), the environment variables it needs, and what it would cost a month on DigitalOcean, AWS, Google Cloud and Azure. Reads the code and changes nothing. Works without signing in. A check can take up to a minute; one still running returns a check_id that fetches its result.

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": "check_repo"
  }
}

Input Schema

NameRequiredDescriptionDefault
repoNoowner/name, or the repository's URL
check_idNoThe check_id of an earlier check, to get its result

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already cover readOnly/destructive, but the description adds genuinely new operational facts: no authentication required, reads code without modifying it, the call can run up to a minute, and a still-running check returns a check_id rather than a result. The non-idempotent annotation is also implicitly explained by the async check_id pattern, so nothing contradicts.

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?

Two sentences, front-loaded with the action and its output, followed by the behavioral caveats (no auth, no mutation, latency, async check_id). Every clause carries information an agent needs; nothing is redundant filler.

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 compensates well by listing the four result categories and the async fallback, and annotations cover the safety profile. Minor gaps remain: whether a check_id expires or how long results persist, and how a partial/failed check is reported.

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, but the description adds meaning the schema lacks: it explains that check_id is produced by this same tool when a check is still running, telling the agent when and why the second parameter exists. The repo parameter gains only the public-repo constraint from the description.

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 verb and resource ('checks whether a public GitHub, GitLab or Bitbucket repository will deploy') and even enumerates what the result contains: detected services, missing items with fixes, required env vars, and monthly cost on four clouds. It does not name or contrast with the nearest sibling (plan_deploy), so an agent must infer the distinction, which keeps it off a 5.

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 only implied: 'works without signing in' and the 'public' qualifier hint at scope, and the check-before-deploy intent is inferable from the returned cost/missing-items payload. There is no explicit when-to-use, no exclusion of private repos, and no routing to alternatives such as plan_deploy or diagnose.

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