Skip to main content
Glama
Sign In

Kosmodrom

by ai.kosmodrom
OverviewDiscussionsAdmin

product_context

Read-only

Returns a product's working context: project, spec excerpt (full spec with includeSpec), product analyst and product lead, unfinished versions with defaultVersionID (the default for new work), repositories and design files. With job, it also returns the workspace conventions and team notes for that kind of work (memoryInstructions) and the memory index of its other notes (ID → title), as reference; notes for other kinds of work are not listed: memoryOtherJobs gives their count per kind of work, and they come in this product context when that kind of work is in job. Notes come in full while the response stays within 44 thousand characters (the client's output limit): a note that does not fit is listed first in the index, and a line above the text gives their number. qaDevices holds the company's QA devices: in full with job qa, in brief with dev and analysis. It also returns the variables that apply in work on the product's tasks for that kind of work (variables), all levels together: for the same path and key the more specific level wins (company, project, repository, user, token); description and location, values of short non-secret environment variables only.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "productID": "<productID>"
    },
    "name": "product_context"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobNoKind of work: analysis - analysis and specs; dev - code and automated tests (local repositories only); qa - manual testing; devops - CI, deployment, servers, logs and performance (code changes and MRs are dev; kinds can be combined, e.g. dev and devops); review - code review; design - mockups; marketing - texts, images, video, SEO, ASO and social media
runKeyNoThe client session ID, as run.runKey when a task is taken: the memory for the job delivered here is not repeated at the take; once the session has taken a task, the conventions for working on a task are included here in full too
productIDYesProduct ID
includeSpecNotrue - full product description in spec; default - first paragraph in specExcerpt
localRepositoriesNoIDs of the product's repositories (repositories[].ID) that the task changes, not every clone on the machine; for review - the repositories of the MR, even without a clone. Repository notes: for dev - only for them, for review and devops - for them when given; no effect on analysis, qa and design

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / job / description
      Previous value: -"Kind of work: analysis - analysis and specs; dev - code and automated tests (local repositories only); qa - manual testing; devops - CI, deployment, servers, logs and performance (code changes and MRs are dev; kinds can be combined, e.g. dev and devops); review - code review; design - mockups"New value: +"Kind of work: analysis - analysis and specs; dev - code and automated tests (local repositories only); qa - manual testing; devops - CI, deployment, servers, logs and performance (code changes and MRs are dev; kinds can be combined, e.g. dev and devops); review - code review; design - mockups; marketing - texts, images, video, SEO, ASO and social media"
    • changedInput schema / properties / job / items / enum
      Previous value: -[
-  "analysis",
-  "dev",
-  "qa",
-  "devops",
-  "review",
-  "design"
-]New value: +[
+  "analysis",
+  "dev",
+  "qa",
+  "devops",
+  "review",
+  "design",
+  "marketing"
+]
    • changedInput schema / properties / job / maxItems
      Previous value: -6New value: +7
  2. Changed2 schema fields changed
    • changedInput schema / properties / localRepositories / description
      Previous value: -"IDs of the product's repositories cloned locally; repository notes for dev - only for them; for review - the repositories of the reviewed MR, even without a clone, which narrows the reviewer's notes"New value: +"IDs of the product's repositories (repositories[].ID) that the task changes, not every clone on the machine; for review - the repositories of the MR, even without a clone. Repository notes: for dev - only for them, for review and devops - for them when given; no effect on analysis, qa and design"
    • addedInput schema / properties / runKey
      Added value: +{
+  "description": "The client session ID, as run.runKey when a task is taken: the memory for the job delivered here is not repeated at the take; once the session has taken a task, the conventions for working on a task are included here in full too",
+  "maxLength": 100,
+  "minLength": 1,
+  "type": "string"
+}
  3. Changed3 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / job / description
      Previous value: -"Kind of work: analysis - analysis and specs; dev - code and automated tests (local repositories only); qa - manual testing; devops - CI, builds, deployment; review - code review; design - mockups"New value: +"Kind of work: analysis - analysis and specs; dev - code and automated tests (local repositories only); qa - manual testing; devops - CI, deployment, servers, logs and performance (code changes and MRs are dev; kinds can be combined, e.g. dev and devops); review - code review; design - mockups"
    • changedInput schema / properties / localRepositories / description
      Previous value: -"IDs of the product's repositories cloned locally"New value: +"IDs of the product's repositories cloned locally; repository notes for dev - only for them; for review - the repositories of the reviewed MR, even without a clone, which narrows the reviewer's notes"
  4. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description still adds real behavioral detail: the 44-thousand-character response ceiling, the truncation rule (the note that does not fit is listed first in the index with a count line above), that notes for other kinds of work are excluded but counted in memoryOtherJobs, and the variable precedence order (company, project, repository, user, token) with secrets excluded. That is substantive context an agent cannot get from the structured fields.

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 lead sentence is correctly front-loaded with what is returned, but the body is one dense run-on block mixing return payload, truncation behavior, job-conditional detail and variable precedence with no separation or bullets. Most sentences earn their place, but the packaging makes it hard to scan.

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?

With five parameters, no output schema and only read-safety annotations, the description properly takes on the burden of describing the return shape and its conditional variations. It is close to complete, missing only a statement of when this context should be fetched instead of the task/session/feature context siblings.

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 supplies cross-parameter semantics the schema does not: job determines which memory/convention set and whether qaDevices is full or brief, runKey suppresses duplicate memory delivery after a task is taken, and localRepositories has no effect on analysis, qa and design. Some phrasing (includeSpec) merely restates the schema, but the interaction rules add genuine meaning.

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 verb and resource and enumerates the concrete payload: project, spec excerpt, analyst, product lead, unfinished versions with defaultVersionID, repositories, design files. An agent can tell what it retrieves, but it never distinguishes itself from closely named siblings such as session_context, task_context, feature_context or repo_context, so the 5 criterion of sibling differentiation is unmet.

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?

Usage is only implied through conditional phrasing ('With job, it also returns...', 'in full with job qa, in brief with dev and analysis'). There is no explicit statement of when to call product_context versus task_context/session_context, nor any exclusion or prerequisite guidance, leaving the agent to infer the routing.

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

All Kosmodrom toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources