Kosmodrom

bug_create

Creates a bug as a draft when the user asks to log a defect; the draft is published separately at the user's request. Placement is one of: a feature (featureID or featureKey), a version (versionID) or the product backlog (productID); type is the criticality (the nature of the defect is the separate bugType field), and bugs always have a testing stage. Stage assignees: employee uuid, "any" (any employee) or null (no such stage; the work stage always exists). Returns the key, link, status and allowed transitions.

Input Schema

Name	Required	Description
`ord`	No	Position of the new bug, as ord in task edits; omitted - the end of the feature's plan.
`gist`	Yes	Gist: one or two sentences, "problem → solution", up to 300 characters of plain text (no Markdown, links or task keys), in the language of the workspace data.
`spec`	Yes	Bug description in Markdown (no HTML) following the bug creation template, in the language of the workspace data.
`type`	Yes	Criticality by actual impact: bug_trivial - cosmetic; bug_minor - inconvenience with a workaround; bug_major - a function works wrong or part of a scenario is unavailable, the workaround is costly; bug_critical - a scenario is impossible, data is lost or corrupted, a section crashes; bug_block - blocks the product or all testing. In doubt between two levels - the higher one.
`build`	No	Build in which the defect was reproduced, from the deployed version.
`fuzzy`	No	Intermittent bug: does not reproduce every time.
`stage`	No	Stand where the bug was reproduced: dev - development and autotests, alpha - manual QA, prod - production data.
`title`	Yes	Bug title, up to 200 characters, in the language of the workspace data.
`labels`	No	Labels.
`browser`	No	Browser where the defect was reproduced.
`bugType`	No	Defect nature: ui - interface, fn - functionality, ux - usability, spec - documentation; not the severity, which is type.
`devices`	No	IDs of devices from the company's QA devices where the defect was reproduced.
`priority`	No	Priority; a human decision, set only at the user's explicit request.
`featureID`	No	Feature ID - the preferred placement
`moduleIDs`	No	IDs of the modules (screens) where the defect is visible.
`productID`	No	Product ID - the product backlog, last resort
`versionID`	No	Version ID - when no feature fits
`featureKey`	No	Feature key #F12; not with featureID
`componentIDs`	No	IDs of the components where the defect is actually visible; empty if unsure.
`testAssignee`	No	Tester: employee UUID or "any" (default) - bugs are always tested.
`workAssignee`	No	Assignee; default "any".
`workTimePlan`	No	Planned fix time in minutes, for the assignee's role level.
`rulesRevision`	Yes	Revision of the bug creation template the spec follows.
`reviewAssignee`	No	Reviewer; default - no review stage.
`approvalAssignee`	No	Approver; default - no approval stage.
`workIterationDate`	No	A date within the work iteration, YYYY-MM-DD; defaults to the current iteration.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 20, 2026

addedInput schema / properties / fuzzy

Added value: +{
+  "description": "Intermittent bug: does not reproduce every time.",
+  "type": "boolean"
+}

addedInput schema / properties / labels

Added value: +{
+  "description": "Labels.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / priority

Added value: +{
+  "description": "Priority; a human decision, set only at the user's explicit request.",
+  "enum": [
+    "postponed",
+    "unset",
+    "inOrder",
+    "important",
+    "urgent"
+  ],
+  "type": "string"
+}

changedInput schema / properties / type / description

Previous value: -"Criticality by actual impact: bug_trivial - cosmetic; bug_minor - inconvenience with a workaround; bug_major - a function works wrong or part of a scenario is unavailable, the workaround is costly; bug_critical - a scenario is impossible, data is lost or corrupted, a section crashes; bug_block - blocks the product or all testing. In doubt between two levels - bug_major."New value: +"Criticality by actual impact: bug_trivial - cosmetic; bug_minor - inconvenience with a workaround; bug_major - a function works wrong or part of a scenario is unavailable, the workaround is costly; bug_critical - a scenario is impossible, data is lost or corrupted, a section crashes; bug_block - blocks the product or all testing. In doubt between two levels - the higher one."

Changed19 schema fields changedOct 8, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

changedInput schema / properties / approvalAssignee / description

Previous value: -"Approver: employee UUID, \"any\" (any employee) or null (no approval stage); default: no approval."New value: +"Approver; default - no approval stage."

addedInput schema / properties / bugType

Added value: +{
+  "description": "Defect nature: ui - interface, fn - functionality, ux - usability, spec - documentation; not the severity, which is type.",
+  "enum": [
+    "ui",
+    "fn",
+    "ux",
+    "spec"
+  ],
+  "type": "string"
+}

changedInput schema / properties / build / description

Previous value: -"Build in which the defect was reproduced, from the deployed version; QA reproduces on it."New value: +"Build in which the defect was reproduced, from the deployed version."

changedInput schema / properties / featureKey / anyOf

Previous value: -[
-  {
-    "maxLength": 12,
-    "minLength": 1,
-    "type": "string"
-  },
-  {
-    "exclusiveMinimum": 0,
-    "maximum": 9007199254740991,
-    "type": "integer"
-  }
-]New value: +[
+  {
+    "maxLength": 12,
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "exclusiveMinimum": 0,
+    "type": "integer"
+  }
+]

changedInput schema / properties / featureKey / description

Previous value: -"Feature key #F12 (or F12, 12); not with featureID"New value: +"Feature key #F12; not with featureID"

changedInput schema / properties / moduleIDs / description

Previous value: -"IDs of the modules (screens) where the defect is visible, even if its cause is in a service."New value: +"IDs of the modules (screens) where the defect is visible."

changedInput schema / properties / ord / description

Previous value: -"Position of the new bug; tasks are ordered by `ord` descending. Omitted - end of the feature's plan, so bugs created one by one keep their order."New value: +"Position of the new bug, as ord in task edits; omitted - the end of the feature's plan."

removedInput schema / properties / ord / maximum
```
Removed value: -9007199254740991
```

changedInput schema / properties / reviewAssignee / description

Previous value: -"Reviewer: employee UUID, \"any\" (any employee) or null (no review stage); default: no review."New value: +"Reviewer; default - no review stage."

addedInput schema / properties / stage

Added value: +{
+  "description": "Stand where the bug was reproduced: dev - development and autotests, alpha - manual QA, prod - production data.",
+  "enum": [
+    "dev",
+    "alpha",
+    "prod"
+  ],
+  "type": "string"
+}

changedInput schema / properties / testAssignee / description

Previous value: -"Tester: employee UUID or \"any\" (any employee); default \"any\" - bugs are always tested."New value: +"Tester: employee UUID or \"any\" (default) - bugs are always tested."

changedInput schema / properties / testAssignee / type

Previous value: -[
-  "string",
-  "null"
-]New value: +"string"

changedInput schema / properties / title / description

Previous value: -"Bug title, up to 200 characters, in the language of the workspace data; states the defect itself, not just the area (like \"Settings\")."New value: +"Bug title, up to 200 characters, in the language of the workspace data."

changedInput schema / properties / workAssignee / description

Previous value: -"Assignee: employee UUID, \"any\" (any employee) or null (no work stage); default \"any\"."New value: +"Assignee; default \"any\"."

addedInput schema / properties / workIterationDate

Added value: +{
+  "description": "A date within the work iteration, YYYY-MM-DD; defaults to the current iteration.",
+  "type": "string"
+}

removedInput schema / properties / workIterationKey

Removed value: -{
-  "description": "Iteration key for work outside the current iteration; default - current",
-  "maximum": 9007199254740991,
-  "minimum": -9007199254740991,
-  "type": "integer"
-}

removedInput schema / properties / workTimePlan / maximum
```
Removed value: -9007199254740991
```
removedInput schema / properties / workTimePlan / minimum
```
Removed value: --9007199254740991
```

Changed2 schema fields changedOct 7, 2026

addedInput schema / properties / browser

Added value: +{
+  "description": "Browser where the defect was reproduced.",
+  "enum": [
+    "any",
+    "chrome",
+    "safari",
+    "opera",
+    "edge",
+    "firefox",
+    "yandex"
+  ],
+  "type": "string"
+}

addedInput schema / properties / devices

Added value: +{
+  "description": "IDs of devices from the company's QA devices where the defect was reproduced.",
+  "items": {
+    "format": "uuid",
+    "type": "string"
+  },
+  "type": "array"
+}

First observedOct 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so safety is covered 'schema-only'. The description adds real value beyond that: the bug is created as a draft and only published on request, bugs always have a testing stage, and stage assignees accept uuid/'any'/null. It also discloses the return contents (key, link, status, allowed transitions), which matters since there is no output schema.

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 create/draft behavior, then the placement and assignee nuances. It is dense but every clause carries information an agent needs for a 26-parameter tool; a slightly more structured list of the placement options would help, but there is little waste.

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 26-parameter creation tool with no output schema, the description covers the important missing pieces: draft lifecycle, placement rules, assignee semantics, and the returned key/link/status/transitions. Remaining gaps (auth needs, validation errors) are minor given the very detailed schema.

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-field interpretation the schema alone leaves implicit: type is criticality, not the nature of the defect (bugType), and placement is a choice among feature/version/product backlog. These distinctions reduce mis-set parameters, though most per-field detail still lives in the schema.

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?

States a specific verb and resource ('Creates a bug') and immediately qualifies it with the draft lifecycle ('as a draft... published separately'), which distinguishes it from a publish operation like task_publish. It also enumerates the placement options and clarifies the type/bugType split, so an agent can tell what the tool does 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?

Gives clear trigger context ('when the user asks to log a defect') and priority guidance for placement: feature is the 'preferred' option, version is 'when no feature fits', and product backlog is the 'last resort'. It does not name sibling tools to avoid, but the placement ordering and draft-vs-publish wording cover the main selection decisions.

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

All Kosmodrom tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep 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?