fettle-mcp

Overview Schema Source Related Servers Discussions Admin

Mark a deploy

record_deploy

Idempotent

Records a deploy's commit or tag, completion time, and affected monitors so later verification and incident checks can identify it as a suspect deploy; it runs no check.

Instructions

Record that a deploy happened: the commit or tag (ref), when it finished (deployed_at) and which monitors it touched (monitor_ids, or tag + tag_match). Fettle stores it so that verify_deploy shows it and a later incident on those monitors can name it as the suspect deploy, with compare_url as the link. It runs no check. Call it only as part of a deploy check the user agreed to, or when the user asks, and only when you know the commit or tag. Repeating the same deployed_at and ref returns the stored marker, so on a retry reuse the exact deployed_at you sent first; a new value records a second deploy. Requires a key with the write scope. Limited to 10 calls per minute per calling address for an API key, per user for an app connection (never per key or organization); past that it is a 429 with the seconds to wait. Example: {"ref": "a1b2c3d", "deployed_at": "2026-11-01T10:02:00Z", "tag": ["service:api"]}

Input Schema

Name	Required	Description
`ref`	Yes	The commit SHA, tag or branch: 1 to 200 printable characters with no spaces; anything else is a 422.
`tag`	No	1 to 10 tags that select the monitors, as in list_tags; not together with monitor_ids. Tags matching no monitor, or more than 100, are a 422.
`tag_match`	No	With tag only: all (default) needs every tag, any needs at least one.
`compare_url`	No	Optional https:// link to the diff, up to 2048 characters; shown as a link and never fetched.
`deployed_at`	Yes	When the deploy finished, ISO 8601 with a UTC offset such as Z; without an offset it is a 422. At most 24 hours back and at most 300 seconds ahead. Together with ref it is the key that makes a retry safe: send the same value again.
`monitor_ids`	No	1 to 100 distinct monitor uuids from list_monitors, paused ones included; not together with tag. A repeated id is a 422; an id that is not a monitor of this organization is a 404 naming it.

Output Schema

Name	Required	Description	Default
`id`	Yes
`ref`	Yes
`created_at`	Yes
`compare_url`	Yes
`deployed_at`	Yes
`monitor_ids`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.3.0Nov 5, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the description is not the sole source of the safety profile. It nonetheless adds real context the annotations cannot: the composite idempotency key (deployed_at + ref), that a new deployed_at records a second deploy, that a write-scope key is required, the 10-per-minute rate limit with its per-address vs per-user scoping, and the 429 response shape. This is well above the annotation baseline and warrants more than a 3.

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?

Content is front-loaded with purpose then constraints, and the example payload at the end is useful rather than filler. The rate-limit and scoping parenthetical is dense enough to slow reading slightly, but no sentence is redundant.

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

Completeness5/5

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

An output schema exists, so return values need no explanation, and the description covers auth scope, rate limiting, idempotent retry behavior, mutual exclusion of selectors and downstream visibility in verify_deploy and incident attribution. Nothing an agent needs to invoke this write correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter including the tag/monitor_ids mutual exclusion, tag_match default and the deployed_at window. The description mostly restates those fields, with the only genuine addition being the operational retry instruction to reuse the exact deployed_at first sent. Baseline 3 applies.

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?

Opens with a specific verb and resource ("Record that a deploy happened") and immediately enumerates the identifying fields. It also distinguishes itself from the nearest sibling by stating "It runs no check," which separates it from verify_deploy without requiring the agent to open either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit positive and negative conditions: call it only as part of a deploy check the user agreed to, or when the user asks, and only when the commit or tag is known. The verify_deploy boundary is stated directly, so the agent has a clear routing rule.

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

Deploy Server