get_rule_context

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

With no annotations provided, the description must carry the behavioral load. It usefully declares read-only access and enumerates the three output keys, but says nothing about permissions, pagination of rule_history, or behavior when a rule_id is missing. Minimal but not misleading.

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

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

Three short, front-loaded lines with no filler; the payload is stated first and the access level follows. The 'Returns:' line is mildly redundant against the existing output schema, which is the only slight waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with a full output schema and an output description, an agent has what it needs to invoke it correctly. The gap is routing context — nothing tells the agent when to prefer this over the overlapping rule-history and audit siblings.

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

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

Schema description coverage is 100% for the single rule_id parameter, including its RN-* format, so the schema already does the work. The description adds no extra parameter semantics, which is the expected baseline when coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb (Return) and a concrete payload: a rule's full text, its complete rule_history, and linked lessons. That is clearly more than a restatement of the name. It does not, however, distinguish this from siblings that also surface rule metadata such as get_rule_timeline, get_rule_audit_log, or query_rules.

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

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

There is no statement of when to use this tool versus get_rule_timeline, get_rule_audit_log, or query_rules, which all touch rule data. The only usage signal is 'Access level: read', which tells the agent it is safe but not when it is the right choice.

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