Skip to main content
Glama
cubicecho

MCP Actual

by cubicecho

Describe the rule format

describe_rule_schema
Read-onlyIdempotent

Returns the exact structure of an Actual rule—condition fields, legal operators, action operations, value types, and examples—so create_rule or update_rule calls avoid rejected field/operator pairings.

Instructions

Return the exact structure of an Actual rule: every condition field with the operators legal for it, the action operations, how values are typed, and worked examples. Call this BEFORE create_rule or update_rule — the condition format is a strict union and an invalid field/operator pairing is rejected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely useful behavior beyond that: the format is a strict union and invalid pairings are rejected, which tells the agent why this call matters. It stops short of describing the response shape in more detail, but the key behavioral trait (validation strictness) is disclosed.

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, both earning their place: the first defines the return payload, the second gives the when-to-call directive and the failure mode. Front-loaded and free of filler.

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?

No output schema exists, but the description narrates exactly what is returned (fields, operators, operations, typing, examples), and a no-param read-only tool needs little else. An agent has everything required to call it correctly and use the result.

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?

Zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly frames this as a no-argument introspection call.

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?

States a specific verb and resource ('Return the exact structure of an Actual rule') and enumerates the contents: condition fields, legal operators, action operations, value typing, and examples. Clearly distinguishable from siblings like list_rules, create_rule, and update_rule.

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 instructs 'Call this BEFORE create_rule or update_rule' and gives the reason (the condition format is a strict union and invalid field/operator pairings are rejected). Names the alternative tools and the condition that selects this one.

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