Keelen

Set UI Review Scenario Cap

set_ui_review_scenario_cap

Set this web_app project's ui-review scenario budget, or reset it.

``scenario_cap`` is an integer from 6 through 32, or ``null`` to reset to
the platform default of 12. The screenshot cap derives from it and moves
with it, so the two can never starve each other.

Raising is always allowed, including from a completely full manifest.
LOWERING is refused when the default branch already declares more scenarios
or screenshots than the smaller budget allows, and is also refused when that
manifest cannot be read — both caps are enforced when keelen pushes and not
in your CI, so an over-cap manifest fails every push while CI stays green.

On a project with the retained evidence catalog (the response carries
``evidence_lifecycle: true``) the same parameter is a CAPTURE-RUN setting:
it limits how many scenarios and screenshots one capture run holds, a pull
request that needs more is split into capture batches, and the catalog
keeps every scenario whatever the value. The response then also reports
``catalog`` (the retained counts) separately from ``run_limits``, and a
lower is not refused for catalog size once the catalog is migrated.

``project_status.ui_review`` reports the live occupancy. Repeated calls with
the same value change nothing.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 3, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With only coarse hint flags available, the description carries real behavioral load: refusal semantics for lowering, the fact that both caps are enforced when keelen pushes and not in CI, the derived screenshot cap that moves in lockstep, and the alternate capture-run semantics when evidence_lifecycle is true (PRs split into capture batches, catalog retained regardless, lower not refused post-migration). It also states that repeated same-value calls change nothing. This is substantially more than the annotations convey.

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 operation, and each paragraph covers a distinct regime (budget cap, catalog capture-run cap, idempotency). It is dense rather than padded, but the third paragraph is long and leans on unexplained internal jargon such as 'keelen pushes', which costs some readability.

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?

Despite the tool's genuinely complex behavior, the description covers allowed values, reset semantics, refusal conditions, enforcement point, the two operating modes, and even the response fields (evidence_lifecycle, catalog, run_limits, project_status.ui_review) beyond what the output schema provides. Nothing an agent needs to call it correctly is missing.

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 compensate, and it does: scenario_cap is an integer from 6 through 32, null resets to the platform default of 12, the screenshot cap derives from it, and its meaning changes to a capture-run limit on catalog projects. The default/sentinel semantics are fully spelled out where the schema gives only an anyOf integer/null.

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?

The first sentence names a specific verb (set/reset) and a precisely scoped resource (this web_app project's ui-review scenario budget). No sibling tool overlaps with this resource, so an agent can select it unambiguously 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?

It gives explicit operating conditions: raising is always allowed, lowering is refused when the default branch already exceeds the smaller budget or the manifest cannot be read, and the cap is enforced on push rather than in CI. It even points to project_status.ui_review for live occupancy. It does not (and need not) compare against sibling tools, but there is no explicit 'use this instead of X' routing.

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.