Skip to main content
Glama
Sign In
DeployAngel

DeployAngel

by DeployAngel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_verification

Check whether a production deployment worked by reading DeployAngel's verdict with its clearance report, failures, findings, and jobs still watched for a commit, version, or deployment ID.

Instructions

Current verdict document for a deployment: state, verdict, confidence, coverage, findings, new exceptions, clearance report, and what is still watched. Defaults to the current git HEAD.

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

Input Schema

NameRequiredDescriptionDefault
commitNoCommit SHA (prefix of 7+ characters is fine).
latestNoUse the most recent deployment.
versionNoRelease version, e.g. v184.
deployment_idNoDeployAngel deployment ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations present, the description carries the full burden. It discloses that the call is a read-style retrieval and what the returned document contains, plus the HEAD default. It says nothing about permissions, rate limits, or how conflicting selectors (e.g. commit and version together) are resolved, leaving meaningful behavioral gaps.

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?

Two sentences, front-loaded with the resource and its contents, with the default behavior stated last. The field enumeration is dense but justified because no output schema exists to carry that information. Minimal waste overall.

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 four-optional-parameter read tool with no output schema and no annotations, the description covers what the agent most needs: what comes back and what happens with no arguments. The remaining gap is selector precedence and any auth or access requirements, which prevents a 5.

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 goes beyond the schema by stating the default selection behavior ('Defaults to the current git HEAD'), which matters because all four selector parameters are optional and the schema never explains what happens when none is supplied. That is real added meaning, though it does not explain precedence among the selectors.

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 names a specific resource ('verdict document for a deployment') and enumerates the concrete contents (state, verdict, confidence, coverage, findings, exceptions, clearance report). That is far more informative than a tautology. It stops short of explicitly distinguishing itself from the sibling 'wait_for_verification', so it lands at 4 rather than 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?

The sentence 'Defaults to the current git HEAD' tells the agent it can call the tool with no arguments, which is genuine usage context. However, there is no statement of when to prefer this over 'wait_for_verification' or how to choose among the four selector parameters, so usage is only implied.

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