marketing-scope-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MARKETING_SCOPE_DATA_DIR | No | Data dir (plans on disk) defaults to ./data; override with MARKETING_SCOPE_DATA_DIR. | ./data |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| plan_campaignA | Turn a campaign objective into a pre-spend plan: offer targets, channel targets, anti-targets (budget black holes), and kill criteria. Purpose: decompose a marketing goal into scoreable tactics BEFORE any spend. Use this before score_offer on any new product/launch; re-plan only when kill criteria trigger. Sibling distinction: score_offer grades ONE offer statement; this plans the whole campaign strategy. |
| score_offerA | Score one offer statement (the exact sentence a prospect would read) on an explainable 0–100 offer-strength scale: clarity 20 / audience specificity 24 / differentiation 20 / proof & risk reversal 20 / call to action 16. Grades: A >= 80, B >= 65, C >= 45, D < 45. Every dimension comes back WITH its evidence, so the number is auditable rather than a vibe. Side effect: the score is cached in an in-memory registry keyed by the exact offer text (lost on restart; re-score before finalizing a plan). Do NOT use it as a general copy critique — it grades offer statements, not landing pages. Sibling distinction: plan_campaign plans the strategy; this grades one sentence; build_plan consumes the scores. |
| build_planA | Build a campaign-plan shell from already-scored offers: strategy stubs, channel briefs, numbered offer registry, scoring appendix. Writes a markdown file under data/campaigns/ and returns the plan id plus the shell text. Do NOT call it before each offer has a score_offer — unscored offer texts are rejected with an error naming them. Sibling distinction: this creates the shell; check_plan later validates everything written against it. |
| check_planA | Verify every substantive campaign tactic (a) cites at least one scored offer from the registry and (b) names a success metric. Violations are returned as an error list — never a silent pass. Read-only tool: inspects the registry and the plan file but writes nothing. Use it after every build_plan and again after any manual edit; do NOT use it on arbitrary markdown that never went through build_plan without first scoring its offers. Sibling distinction: build_plan creates the registry-backed shell; check_plan validates whatever is on disk against that registry. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose with explicit sibling distinctions: plan_campaign plans strategy, score_offer grades a single offer, build_plan constructs the plan shell, and check_plan validates. No overlapping purposes or ambiguous boundaries.
All tool names follow a consistent snake_case verb_noun pattern: plan_campaign, score_offer, build_plan, check_plan. The convention is predictable and readable throughout.
Four tools exactly cover the campaign planning workflow—plan, score, build, check—each earning its place without redundancy or bloat. The count matches the scope perfectly.
The tool set covers the full lifecycle from initial strategy planning through offer scoring, plan construction, and final validation against the registry. No obvious gaps for the stated marketing-scope domain; agents can complete the intended workflow end-to-end.