get_rulesRead the person's filing rules before organizing documents so the AI follows their approved naming and filing preferences.
The person's filing rules. Read first.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.1Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "additionalProperties": true,
- "title": "Result",
- "type": "object"
- }
- },
- "required": [
- "result"
- ],
- "title": "get_rulesOutput",
- "type": "object"
-}New value: +nullv0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered and the bar is lower. The description adds only that the rules belong to "the person" (per-user scoping) and that reading precedes other work; it says nothing about payload size, freshness, or whether the rules can be empty.
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?
Two fragments, zero waste, with the identifying information first and the actionable ordering hint second. It is arguably over-compressed rather than padded, but every word present earns its place.
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?
There is no output schema, so the description carries the full burden of explaining what comes back — and it does not, beyond the vague noun "rules." For a prerequisite tool that the agent is told to call before everything else, the absence of any return-value or format guidance is a real gap.
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?
The tool takes zero parameters with 100% schema coverage, so there is nothing for the description to disambiguate. Baseline 4 applies; the description could only improve by confirming that no input is needed, which is a minor omission.
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 person's filing rules" identifies the resource but supplies no verb — an agent must infer that this retrieves/reads them. It is distinguishable from siblings like structure_advice or naming_examples by topic, but only weakly, since nothing states what a "rule" is or how the payload differs from those siblings' outputs.
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?
"Read first" is a genuine ordering directive that tells the agent to consult this before acting, which is more than most siblings get. However, it names no alternatives and gives no condition for when rules are irrelevant or when to re-read them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.