Loading ToolBench
Model Context Protocol (MCP) server for DeployHQ API integration
DeployHQ MCP server demonstrates solid tool definition quality with consistent schemas, clear descriptions, and proper annotations. All 18 tools have explicit definitions with input schemas and descriptions. Tool naming follows verb_noun conventions (list_*, get_*, create_*, update_*, delete_*) which is excellent for LLM parsing. However, several issues prevent a higher score: (1) output schemas are not documented, the server defines inputs but never specifies what fields clients should expect in responses; (2) some parameter descriptions are generic and lack actionable constraints (e.g., 'Branch to deploy from' doesn't specify format); (3) no explicit guidance on which operations are idempotent or retryable; (4) error handling strategies are not visible in the tool definitions; (5) pagination support exists for list_deployments but guidance on total counts and result limits is absent. The server handles the common case well, straightforward CRUD tools with proper type safety via Zod, but lacks depth in production-grade patterns like partial failure handling, dependency hints, and recovery guidance.
Create a new deployment for a project. Can queue for immediate deployment or create a preview. Requires server UUID and commit revisions.
Create a new global configuration file. These files can be used across all projects for storing shared configuration.
Create a new global (account-level) environment variable. These variables are available across all projects.
Create a new SSH key in the account. DeployHQ will generate the key pair and return the private key for download.
Delete a global configuration file.
Delete a global (account-level) environment variable.
Output schemas are not documented. Tool definitions specify input schemas but do not declare what fields or structure clients should expect in responses. This forces LLMs to guess at response structure and plan downstream tool chains without confirmed field names.
Parameter descriptions lack actionable constraints. Many parameters are described generically (e.g., 'Branch to deploy from') without specifying format, allowed values, examples, or constraints. This invites LLM hallucination of invalid inputs.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | B | 70 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 63 | 2024-11-05+ | v1 |
Get detailed information about a specific deployment including its status, logs, files changed, and server details.
Get the deployment log for a specific deployment. Returns the complete log output as text, useful for debugging failed or completed deployments.
Get the full details and contents of a specific global configuration file.
Get detailed information about a specific project including repository details, SSH keys, and deployment URLs.
List deployments for a project with pagination support. Returns deployment status, timestamps, revisions, and server information. Can be filtered by server UUID.
List all global (account-level) configuration files. These files are available for use across all projects.
List all global (account-level) environment variables. These variables are available across all projects in the account.
List all projects in the DeployHQ account. Returns project names, permalinks, repository information, and deployment status.
List all servers configured for a project. Returns server names, hostnames, protocols, paths, and deployment settings.
List all SSH keys configured in the account. Returns key titles, public keys, key types, fingerprints, and account scope information.
Update an existing global configuration file.
Update an existing global (account-level) environment variable. Can update name, value, locked status, or build pipeline flag.
No documented pagination limits or result set expectations. list_deployments and list_projects accept pagination but tool descriptions do not state maximum result counts, what happens at limits, or how to handle large data sets. This risks context window overflow.
Destructive operations (create_deployment, delete_global_environment_variable, delete_global_config_file) lack confirmation or dry-run guidance. Tool definitions do not document recovery strategies, rollback procedures, or how to safely test destructive operations.
Error handling recovery guidance is absent from tool definitions. Tool descriptions do not explain what errors are retryable, which are user-fixable, or what the LLM should do when a call fails. This leaves agents unable to recover intelligently.
Missing idempotency declarations. Tool definitions do not state which operations are idempotent (safe to retry) and which have side effects. Agents rely on this information to decide whether to retry on ambiguous failures.
Parameter dependency documentation is incomplete. create_deployment has complex conditional logic (use_latest overrides start_revision) but these dependencies are not documented in parameter descriptions. Agents cannot reason about parameter interactions.