Kaiku

Report deployment

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

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.6/5.0

Behavior5/5

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

Goes far beyond the annotations: it discloses side effects (issues get 'deployedTo', one history line per environment, project rules with trigger 'deployed' run), idempotency semantics ('repeated': true on same id+environment so a re-run is safe), permission requirements, and return contents including 'unknown' and 'unfinished'. This is exactly the mutation context an agent needs.

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?

Front-loaded with the core action and the environment definition, then progressively adds range semantics, idempotency, and return shape. It is dense and em-dash heavy with some redundancy (environment defined at length, repeated mentions of key reading), but nearly every sentence carries usable information.

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?

With 11 parameters, no output schema, and a mutation operation, the description still covers inputs, side effects, idempotency, permissions, and the shape of the response including edge-case fields ('unknown', 'unfinished', rule run counts). Nothing material for correct invocation is missing.

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 already 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema does not: how 'from'/'to' resolve commit keys via the connected repository (merge commits naming branch/MR), how 'id' relates to 'revision', and how 'version' affects all listed issues. It is complementary rather than repetitive, though some phrasing overlaps the schema text.

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?

The description opens with a specific verb+resource ('Say that something was deployed to one of a project's environments') and immediately defines the domain objects (environment, deployment) relative to siblings like get_issue and list_environments. An agent can distinguish this from set_environments or release_version without opening the schema.

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 states the calling context ('the call a pipeline step makes') and explains the two ways to supply issues ('name the issues in issues, or give from and to'), noting both may be given. It routes to list_environments for valid environment names, but gives no explicit when-not guidance or comparison against alternative reporting tools.

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?