What Matters

manage_rule

Create, change, pause or delete a standing rule, taking effect IMMEDIATELY with no review. Use this only when the user asks you directly — "stop suggesting PTO stuff". A scheduled run must propose rules through put_proposal instead, exactly as it proposes items rather than calling add_item.

Input Schema

TableJSON Schema

Name	Required	Description
`rule`	No	Required for create.
`patch`	No	Fields to change, for update.
`rule_id`	No	Required for update, pause, resume and delete.
`operation`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses a critical behavioral trait: rules 'tak[e] effect IMMEDIATELY with no review'. While it doesn't detail reversibility or permissions, the most safety-relevant behavior is clearly communicated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and then the usage constraint. Every word earns its place; no redundancy.

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?

Given the complex schema and no output schema, the description covers the essential selection context and key caveat. The schema handles parameter details and required fields. It could explicitly mention that 'create' requires the rule object, but the schema already implies this.

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

Parameters3/5

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

Schema description coverage is high (75%), with rich descriptions for channel, section, and reason. The description adds no parameter-level detail, but the schema already documents the parameters adequately, so the baseline 3 is appropriate.

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 description uses specific verbs 'Create, change, pause or delete' and identifies the resource as 'standing rule', clearly distinguishing it from siblings like put_proposal and add_item. The scope is immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use this only when the user asks you directly' and provides an example ('stop suggesting PTO stuff'). It also names the alternative tool for scheduled runs (put_proposal) and explains why, making the usage boundary unambiguous.

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

All What Matters tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct resource (items, focus, rules, proposals) with clear action verbs, and the descriptions explicitly delineate when to use add_item vs put_proposal and warn against using manage_focus/manage_rule outside conversation, leaving no ambiguity.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (add_item, complete_item, get_document, manage_focus, manage_rule, put_proposal), with verbs conveying the action and nouns the target.

Tool Count5/5

Six tools is well-scoped for this server: core item operations (add, complete, read), auxiliary resource management (focus, rules), and a proposal mechanism. Each tool has a distinct, non-redundant purpose.

Completeness3/5

The surface covers item creation, status changes, and reads, plus focus and rule management, but lacks direct item deletion or content editing; dismissal is mentioned in get_document but no tool performs it, requiring workarounds via proposals.

Resources

Need Help?