Skip to main content
Glama

mkt_channel_plan

Generate a read-only channel plan that maps goals to primary, launch, support, and observer channels with economics ranges, capacity limits, and preregistered experiments.

Instructions

只读渠道方案:目标→主/发射/辅助/旁听 + 经济学区间 + 容量 + 预注册实验。

Input Schema

NameRequiredDescriptionDefault
goalYes
factsYes
platformsNo
secondaryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.0

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full burden, and it does deliver one important behavioral fact: the tool is read-only (只读). It also discloses the shape of what comes back (economics ranges, capacity, pre-registered experiments), which is useful given there is no output schema. Missing are what `facts` must contain, whether any state is persisted, and error behavior.

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?

A single sentence with zero filler, front-loaded with the read-only qualifier and then the output components. The arrow-and-slash compression is terse to the point of being cryptic, but nothing is redundant.

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

Completeness2/5

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

This is a two-required-parameter tool with an undocumented nested object, no annotations, and no output schema, yet the description is one short clause. It should explain what `facts` supplies and how the tool differs from the adjacent channel/planning siblings; as written, an agent lacks enough to call it reliably.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate — and it only implicitly covers `goal` (目标). The three other parameters, including the required nested `facts` object and `platforms`/`secondary` arrays/strings, receive no explanation of expected structure or contents. An agent cannot fill `facts` correctly from this definition.

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

Purpose3/5

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

The description names the artifact (渠道方案 / channel plan) and enumerates its components: primary/launch/auxiliary/observer channels, economics range, capacity, and pre-registered experiments. However, it uses compressed arrow notation (目标→主/发射/辅助/旁听) with heavy domain jargon and no explicit verb, so an agent must infer that it *generates* a plan rather than reads one. It never distinguishes itself from near-siblings like mkt_channels or mkt_goal_plan.

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

Usage Guidelines2/5

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

There is no when-to-use guidance at all — no statement of the situation that selects this tool over mkt_channels, mkt_channel_venues, mkt_goal_plan, or mkt_strategy. The '只读' prefix hints it is a non-mutating planning step, but the agent is left to guess the ordering and preconditions.

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