Keelen

Get Project Digest

project_digest

Read a compact progress digest for one project (delivery, activity, holds, next decision).

Returns the closed MCP projection: delivery counts and the five newest
delivered items, a recent loop-activity count, current holds, the single
highest-priority open decision, and `more_decisions`. Two steering fields
are ALWAYS present: `next_action` is `"call_tool"` with
`next_tool="list_escalations"` when a decision exists, otherwise
`"none"` with `next_tool: null`. `steering_rules` is also ALWAYS present
with `suggested_retire_count`, `message` and `settings_path`; the advisory
backlog is computed outside the activity window, so a digest with no
recent activity can still show it. `since` is an optional ISO-8601
timestamp with a timezone; it defaults to 24 hours ago and is clamped to
the last seven days. Tenant-scoped: a project outside the caller's
workspace 404s.

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_digest"
  }
}

Input Schema

Name	Required	Description	Default
`since`	No
`project_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 1, 2026

TDQS

A3.6/5.0

Behavior1/5

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

The description frames the operation as a pure read ("Read a compact progress digest", "advisory backlog is computed outside the activity window"), while annotations declare readOnlyHint=false and idempotentHint=false, implying possible state change. It supplies rich context on defaults, clamping and 404 behavior, but that direct read/write conflict is not reconcilable from the text, so the annotation contradiction dominates.

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 purpose, then return payload, then parameters — a sensible order with no filler sentences. It is somewhat long because it enumerates output fields and steering contracts that an output schema may already carry, but each clause states a concrete contract, not padding.

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?

Covers scope, error behavior (404 for out-of-workspace projects), parameter defaults/clamping, and the always-present steering fields, which is near-complete for a two-parameter digest whose output schema is already published. The one missing piece is any statement about whether calling it has side effects, which would have resolved the annotation conflict.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it does: `since` is specified as an optional ISO-8601 timestamp with timezone, defaulting to 24 hours ago and clamped to seven days — far beyond the bare `anyOf[string, null]` schema. `project_id` gains semantics through the tenant-scoping/404 statement.

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?

Opens with a specific verb and resource ("Read a compact progress digest for one project") and parenthetically enumerates the digest's domains (delivery, activity, holds, next decision), which distinguishes it from project_status and open_dashboard. An agent can predict the payload shape before opening any schema.

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 context is implied ("one project", tenant-scoped) but the description never states when to prefer this over sibling tools like project_status, get_product_goal, or open_dashboard, nor any when-not condition. The only explicit routing guidance is inside the return value (`next_tool="list_escalations"`), not about when to call this tool itself.

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

All Keelen tools Inspect

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.