Kaiku

report_deployment

Say that something was deployed to one of a project's environments — the call a pipeline step makes. An environment is one of the places a project's work is put out to — 'dev', 'staging', 'prod' — in order; the LAST one is where finished work ends up. A deployment is a pipeline saying «this went out, there». Each issue it carried then says where it lies ('deployedTo' on get_issue), gets one history line per environment, and the project's rules with trigger 'deployed' run on it. Name the issues it carried in 'issues', or give 'from' and 'to' — two revisions — and the keys are read off the messages of the commits between them in the project's connected repository (a merge commit names its branch and merge request). Both may be given. The same 'id' for the same environment again changes nothing and answers 'repeated': true, so a step that runs twice is safe. 'version' also puts each of those issues in that version of the project. Answers with the issues it found, 'unknown' (keys you named that are no issue of this project), how many times a rule ran, and — on the project's last environment — 'unfinished': the issues that went out while not in a finished state. Needs permission to change issues in the project.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Your own identifier for this deployment — a pipeline or job id. Left out, 'revision' stands in for it.
`to`	No	The end of that range. Left out, 'revision'.
`url`	No	A link to the pipeline, http or https.
`from`	No	The revision the previous deployment to this environment was at — the start of the range of commits to read keys from.
`issues`	No	The issue keys it carried, comma-separated: 'ONB-12,ONB-15'.
`version`	No	A version of the project to put these issues in, by name, e.g. '2.4.0'.
`fromLast`	No	True to start the range at the revision the last deployment to this environment was reported at, instead of naming 'from'. The first report to an environment then reads no range.
`revision`	No	What went out: a commit, a tag, an image tag.
`projectKey`	Yes	Project key, e.g. 'ONB'.
`repository`	No	Which connected repository the range is in, as 'group/repo', when the project has several.
`environment`	Yes	The environment's name, e.g. 'staging' — one of list_environments.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

addedInput schema / properties / fromLast

Added value: +{
+  "default": false,
+  "description": "True to start the range at the revision the last deployment to this environment was reported at, instead of naming 'from'. The first report to an environment then reads no range.",
+  "type": "boolean"
+}

AddedOct 5, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses idempotency ('same id for the same environment changes nothing and answers repeated: true'), side effects (history lines, 'deployed' rules firing, version assignment), a permission requirement, and the return shape including 'unknown' and 'unfinished' on the last environment.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is long, em-dash-heavy, and includes definitional filler—'An environment is one of the places a project's work is put out to'—that an agent selecting a tool does not need. Several sentences earn their place; several do not.

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 an 11-parameter mutation tool with no annotations and no output schema, the description is unusually complete, covering inputs, idempotency, side effects, permissions, and return fields. It stops short of error/failure behavior and exact response field names beyond 'repeated', 'unknown', and 'unfinished'.

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 cross-parameter semantics the schema can't: the from/to range is read off commit messages of the connected repository, merge commits name their branch and MR, fromLast is the alternative to 'from', and 'id' controls idempotency keyed on the environment.

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 states a specific verb+resource—recording that something was deployed to a project environment—and frames it as the pipeline-step call. It distinguishes itself well from siblings, none of which record deployments, though it takes several sentences of narrative to get there.

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

Usage Guidelines4/5

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

It explains the operating context ('the call a pipeline step makes'), the two ways to identify issues ('issues' or a 'from'/'to' range, which may be combined), and the prerequisite ('permission to change issues in the project'). It references related tools (get_issue, list_environments) but never explicitly states when to prefer this over alternatives.

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

All Kaiku tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?