Skip to main content
Glama
Sign In

Keelen

by io.github.jamie7893
OverviewDiscussionsAdmin

Get Project Status

project_status

Check how a project is doing: what is in flight, what shipped, what is stuck.

Returns lifecycle status, open task count, queued roadmap item count, runs
today, verification pass rate, open blockers, pause state, and freshness.
Zero `open_tasks` does not mean an empty roadmap: `queued_roadmap_items`
counts planned work awaiting expansion, including work held while the
scheduler is disabled. list_roadmap returns those items.

Delivery vs verification: `prs_merged_today` is the DELIVERY signal
(distinct PRs merged today). `pass_rate` is the local verification pass
rate over the last 14 days of dev/QA iterations - NOT a delivery measure.
`verify_decided_14d` is that ratio's denominator and `verify_errored_14d`
its sandbox-timeout share: when errored dominates, pass_rate measures the
verify budget, not the code. `open_escalations` is a COUNT; read
list_escalations for the rows.

Pause state is `scheduler_enabled`, `scheduler_paused_until` and
`pause_reason`. Freshness is `last_iter_at`, `last_pm_iter_at`, and
`last_successful_deploy_at` (a LEGACY pointer); read `deployment {merged,
deployed, verified, last_deploy_attempt}` for the three facts kept
separately, and treat only `verified` as a verified deployment.

`pm_lane {last_pm_iter_at, repo_access}` is the planning lane's live
health: repo_access 'failing' means that lane cannot read the repo from
GitHub even while runs still start and `github_connected` reads true (that
flag is presence-only).

`glm_peak_paused` is NOT a fault and sets no pause columns: it is the
ephemeral GLM peak-hours skip. True means clean PRs hold and runs stop
until `glm_peak_resumes_at`. It is an intentional cost gate, so the accurate
description is "waiting for off-peak", not a failure.

`ui_review` is absent while the ui-review autonomy ladder is enabled (the
default): the ladder owns that budget and the customer surface carries no
scenario or capture controls. In the legacy mode it is present for
`web_app` projects and reports scenarios/scenario_cap/captures/capture_cap
from the default branch's `ui-review.json` (both caps are enforced at push
time, not in your CI); it can mint a GitHub installation token to read it,
so the call is then not guaranteed to be a purely local read.

`model_roles` (only when the Researcher/Integrator feature is enabled for
the project) reports each optional stage's on/off configuration and last
outcome.

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": {
      "project_id": "<project_id>"
    },
    "name": "project_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: `glm_peak_paused` is an intentional cost gate and not a fault, `pass_rate` is not a delivery measure and degrades when `verify_errored_14d` dominates, `ui_review` is absent by default because the autonomy ladder owns that budget, and in legacy mode the call can mint a GitHub installation token so it is "not guaranteed to be a purely local read" — which also explains the non-read-only hint.

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?

Front-loaded with a strong one-line summary and organized into topical paragraphs, which keeps it navigable. But it runs several hundred words and the "Returns lifecycle status, open task count, ... " sentence largely restates the output schema, so a meaningful share of the text is redundant given a schema already exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Field-level semantics are unusually thorough and an output schema exists, so return values are well covered. Gaps remain: no guidance on the required `project_id`, no error behavior, and no differentiation from `project_digest` or `get_product_goal`, which an agent choosing among status-reporting siblings would need.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter `project_id` has 0% schema description coverage, so the description carries the full burden — yet it never mentions the parameter, its format, or where to obtain an id (e.g. via list_projects). The prose is entirely about return fields, leaving the only input undocumented in both places.

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?

Opens with a concrete verb+resource framing ("Check how a project is doing") and enumerates exactly what the payload covers, so the agent knows this is the aggregate status view rather than a row-level read. It never distinguishes itself from the similarly scoped `project_digest` sibling, which is the one remaining ambiguity about what this tool is for.

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 explicit routing to alternatives in two places: `open_escalations` is a count and "read list_escalations for the rows", and `queued_roadmap_items` is expanded by `list_roadmap`. It never states when *not* to call this (e.g. when a per-project digest would suffice), so partial credit.

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

All Keelen toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources