Skip to main content
Glama

tree_rule

Lists, registers, or removes data-defined validation rules as boolean expressions over tree structure and node parameters, so checks can flag the exact node that breaks a constraint.

Instructions

The tree's checks, as data. No arguments: list the rules. With name + expr: register one — a boolean expression whose builtins are STRUCTURAL only (param, nodes, params_of, count, sum/len/abs/min/max, ctx, superseded, unsupported(p, rel) — how many of what p leans on via rel are superseded or gone, so a rule can ask whether a claim's supports still stand — uses/where_used, the reuse folds rollup(under, mult, value) / tally(under, kind, mult) — mult/value name params, data not schema — the trace verbs over event subtrees: before(a, b) document order, preceding/following(p, kind?) earlier/later siblings, index(p), at(parent, i), parent(p) — so a scenario whose children are events is checkable ('the confirmation email precedes the charge') — and and/or/not) plus one bridge to meaning: solve('contract', args…), e.g. solve('geometry/bbox_h', 'pieces/x'). Contracts come from packages. Scope with kind (per node of that kind; its params + self in scope) or path; neither = global. Rules run in tree_check; remove deletes one.

Input Schema

NameRequiredDescriptionDefault
exprNo
kindNo
nameNo
pathNo
removeNo
descriptionNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description discloses key lifecycle behavior: registration, deletion via `remove`, and execution through `tree_check`. However, it does not mention permissions, reversibility, duplicate-name handling, validation behavior, or side effects of registration. The expression-language details add context, but mutation behavior remains only partially transparent.

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?

The core modes are front-loaded, but the description becomes a dense single paragraph with a very long parenthetical and nested dashes. The expression-builtin list is useful, but the structure makes it harder to parse than necessary. It is not redundant, but it is not concise or well-structured.

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?

For a complex rule-management tool with a custom expression DSL, the description covers the main modes, scoping, expression builtins, and the `tree_check` execution link. The output schema exists, so return values need not be explained. It is still missing the `description` parameter and some mutation-behavior details, but it is largely complete for invocation.

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 0%, so the description must carry parameter meaning. It explains `name`, `expr`, `kind`, `path`, and `remove` well, including the expr builtins and scoping semantics. It omits any explanation of the `description` parameter, which is a clear gap for a 6-parameter tool.

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 clearly states the tool's modes: with no arguments it lists rules, with name + expr it registers one, and `remove` deletes one. It also distinguishes rule management from execution by noting that rules run in `tree_check`. This is a specific verb-and-resource statement with sibling differentiation.

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 explicitly says how to use each mode (no args to list, name + expr to register, remove to delete) and how to scope rules with `kind` or `path`. It also tells the agent that rules run in `tree_check`, giving a clear operational context. It does not explicitly state when not to use the tool or compare it to other siblings beyond `tree_check`.

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