Skip to main content
Glama

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.

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
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. 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"
+}
  2. 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"
  3. First observed

TDQS

A4/5.0
Behavior5/5

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

Annotations only confirm this is a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), yet the description layers on rich disclosure: the 44k character truncation rule and how a non-fitting note is surfaced, that memoryOtherJobs holds counts for other kinds of work, that QA devices are full with 'qa' and brief with 'dev'/'analysis', and that variables resolve by level precedence (most specific wins). These are non-obvious behaviors an agent must know and are not derivable from the schema or annotations.

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?

Content is front-loaded with the core return shape and almost every clause carries information (no filler), which is appropriate for a tool with this many conditional branches. However it is delivered as one dense run-on paragraph with nested parentheticals and semicolon-chained conditionals, making it hard to parse and forcing the agent to re-read to extract the mode-specific rules.

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?

There is no output schema and this is a complex five-parameter tool with conditional return shapes, so the description must carry the full burden of explaining what comes back — and it does, covering spec, memory/notes, qaDevices, repositories and variables including truncation and precedence rules. An agent has enough to call it and interpret the response correctly.

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 description coverage is already 100%, so the baseline is 3, but the description adds meaning tied to parameters: that 'job' controls which conventions/notes are returned and the detail level of qaDevices, that 'runKey' prevents memory being repeated at take and pulls in task conventions in full, and that 'localRepositories' affects repository notes specifically for dev/review/devops while having no effect on analysis/qa/design.

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 opens with a specific verb and resource: 'Returns a product's working context', then enumerates exactly what that context contains (project, spec excerpt, analyst/lead, versions, repositories, design files). It is far more specific than a tautology, but it never names a sibling (feature_context, task_context, repo_context, product_list) to help an agent disambiguate among the many *_context and *_list tools.

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?

The description extensively explains how behavior changes conditioned on 'job', 'runKey', 'includeSpec' and 'localRepositories', which implies when each mode is appropriate (e.g. dev vs qa vs design for memory and qaDevices detail). However, it never states when to call product_context instead of another context tool, nor any exclusions or prerequisites beyond the runKey note.

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
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