mcp-server

get_rule

Read-onlyIdempotent

Get the full definition of one product rule (Attribute Rule), including its verbatim rules[] (round-trippable — you can edit it and pass it back to update_rule). Use this to read a rule before changing or reusing it. Returns {ruleId, name, description, category, scope, rules, createdAt, updatedAt}. rules[] is {sortId, enabled, type, conditions, operationGroups:[{mode, parentMode, attributes, operations:[{name, arguments}]}]} (see list_rule_transforms). scope selects the library: 'project' (default) or 'shared_template'. An unknown rule_id returns error 'not_found'. rule_id is from list_rules. project_id is OPTIONAL (inferred for a single-project customer; project_id_required otherwise — then call list_projects).

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": {
      "rule_id": "<rule_id>"
    },
    "name": "get_rule"
  }
}

Input Schema

Name	Required	Description
`scope`	No	Which library to read from: 'project' (default) = the project's own rules; 'shared_template' = the reusable shared template library.
`rule_id`	Yes
`project_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantial extra context: the exact returned field set, the nested rules[] structure and that it is round-trippable into update_rule, the 'not_found' error on an unknown rule_id, and the project_id_required fallback path. That is real behavioral disclosure beyond the structured fields.

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?

Purpose and round-trip note are front-loaded, then return shape, then parameter details — good ordering with no filler sentences. It is dense, with heavy parenthetical nesting in the rules[] structure explanation, which costs a little readability but nothing is truly extraneous.

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?

With no output schema, the description carries the return-shape burden itself and does so, listing the top-level fields and the nested operations structure plus a pointer to list_rule_transforms. Error semantics and the project_id resolution path round out what an agent needs to call it correctly.

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 coverage is only 33%, but the description compensates fully: rule_id is sourced from list_rules with a documented not_found failure, project_id is described as OPTIONAL and inferred for single-project customers with a documented fallback to list_projects, and scope is tied to which library is read. Each of the three parameters gains meaning the schema alone does not supply.

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 ('Get the full definition of one product rule (Attribute Rule)') and immediately scopes it against the list-level sibling by noting rule_id comes from list_rules. An agent can distinguish this from list_rules and update_rule without 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 Guidelines4/5

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

Explicitly says 'Use this to read a rule before changing or reusing it', which tells the agent when to reach for it, and points at list_rules to obtain the ID. It does not spell out a 'do not use this when...' case, but the read-vs-list boundary is clear enough from the purpose statement.

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

All mcp-server 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.

Resources

Need Help?