Retrieve exact JSON schema and accepted enum values for creating or updating Rewrite Rules and Actions, so you can build valid LemonMCP rewrite configurations.
Returns the exact JSON schema and accepted enum values for creating or updating Rewrite Rules and Actions.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Returns' strongly implies a non-mutating introspection call and naming the returned payload (JSON schema + enum values) is informative, but it says nothing about whether this is a static or runtime-derived schema, caching, or failure modes.
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?
A single front-loaded sentence that identifies the verb, the return payload, and the domain. No filler, nothing to trim.
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?
With no output schema, the description does tell the agent what comes back (JSON schema and enum values), which is the key information for a schema-discovery tool. It lacks guidance on how the result should be used in a create/update workflow, keeping it just short of complete.
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, so there is nothing for the description to disambiguate; the schema field itself is empty and 100% covered. Baseline 4 applies for a no-parameter tool.
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?
States a specific verb ('Returns') and resource ('the exact JSON schema and accepted enum values for creating or updating Rewrite Rules and Actions'), which clearly separates it from siblings like upsert_rewrite_rule or list_rewrite_rules. It never names an alternative explicitly, so it falls short of a 5.
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?
The mention of 'creating or updating Rewrite Rules and Actions' implies the tool is used to discover valid fields/enums before calling upsert_rewrite_rule, but it never states when to use this versus validate_module_package or the script-package validators. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.