Validates a marketing plan.json for schema completeness, channel capability, wave size against core daily budget, and preregistered failure criteria; returns an error list where empty means pass.
校验营销计划 plan.json：schema 完整性、渠道能力矩阵、波次规模不超内核日预算、失败判据预注册。返回错误清单，空=通过。只读。
| Name | Required | Description | Default |
|---|---|---|---|
| plan_path | Yes | plan.json 路径 |
Changes observed during successful MCP inspections.
v0.13.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full load. It does disclose the most valuable behavior: it is read-only and returns an error list where empty means pass, which is genuinely beyond what the schema says. It still omits what an error entry looks like, whether it collects all errors or stops at the first, and how a missing/unreadable path surfaces.
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?
Compact and front-loaded: the verb and resource lead, the check categories are a tight enumeration, and the return semantics plus read-only flag close it out. Every clause carries information, though the colon-chained list is dense enough that a non-Chinese-reading agent may parse slowly.
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 linter with no output schema, the description does the important work: it names the checks, states that the return is an error list, and defines the pass condition. What remains missing – error record structure and path base – is minor for a read-only validation tool.
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?
There is a single parameter with 100% schema description coverage ('plan.json 路径'), so the schema already documents it. The description adds no meaning about path resolution, relative-to-what base directory, or acceptable file naming, so it merely matches the schema rather than extending it.
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?
A concrete verb (校验/validate) applied to a specific resource (营销计划 plan.json), followed by an enumeration of the four check categories it runs. It is clearly a linter, but it never distinguishes itself from nearby siblings such as mkt_channel_plan, mkt_sprint_plan, or mkt_voice_lint, which an agent could mistake for the validation entry point.
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?
Usage is only implied: an agent can infer this is a pre-flight check on a plan file. There is no explicit statement of when to call it versus building a plan with a sibling, no prerequisites (does the plan need to exist first?), and no exclusions. '只读' implicitly tells the agent it is a safe inspection step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.