Mark

Save Strategy Item

save_strategy_item

Idempotent

Creates or updates one strategy item: kind = persona | pillar | angle | market | buyer_question | kpi_target. Personas, pillars and angles are the Messaging page (/settings/messaging); an angle is one persona × pillar pair, so create it with fields.personaId and fields.pillarId from get_brand_context. Markets are the Markets page (/settings/markets); to add one from a place name, set_up_market resolves the codes for you. Pass id to update an existing item. For a persona, pillar, angle or market, send only the fields that change; the rest, and the active flag, keep their saved values. Pillar and angle slugs cannot change after creation. A new market without priority goes after every existing one; a locationCode and languageCode pair must be one list_market_locations returns. Pass id and active only (no fields) to deactivate (false) or reactivate (true) a persona, pillar, angle, market, or buyer question without deleting it. KPI targets are the Targets page (/settings/targets): one target per metric per month. Saving a metric and month that already has one is refused with that target's id; to change it, pass its id and fields.value only (metric and month cannot change). engagement_rate is a percent: send 4.5 for 4.5%. KPI targets have no active flag — passing active is refused. Delete a KPI with delete_strategy_item. Read targets with their actuals and progress from get_content_performance (kpis). Buyer question text cannot be edited in place — create a new one, or retire with active: false. A buyer question's topic (a short label, max 60 characters) can change any time: pass id with fields.topic, or empty to clear. It touches no past or future check. Creating a buyer question also returns item.firstCheck { questions, markets, engines, checks }: what the next AI answer check sends (active questions × active markets with a location × engines). suggest_buyer_questions lists questions to start with. Returns appUrl, the page where a person sees the item. Related: get_brand_context, suggest_buyer_questions, delete_strategy_item, set_up_market, list_market_locations, get_content_performance.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Existing item id. Omit to create.
`kind`	Yes	Which kind of strategy item.
`active`	No	false retires the item without deleting it.
`fields`	No	Kind-specific fields. persona: name, slug, wants, convincedBy (list), objections (list; put the answer in the line as objection: answer), pains (list), jobs (list: jobs to be done), language (list: phrases the customer uses, in their words). pillar: name, slug, formats (list), notes. angle: name, slug, personaId, pillarId. Lists and notes are optional on create. market: name, country (ISO code such as US), timezone (IANA, such as America/New_York), priority (lower comes first; optional on create), locationCode and languageCode (from list_market_locations; null clears them). buyer_question: question, topic (optional; a short label, max 60 characters; empty clears it). kpi_target: metric (posts_per_week \| impressions \| engagement_rate \| leads \| qualified \| rejection_rate \| cost_per_lead), month (YYYY-MM), value (zero or more, up to 4 decimal places; engagement_rate in percent, so 4.5 means 4.5%).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`item`	Yes
`kind`	Yes
`appUrl`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

changedInput schema / properties / fields / description

Previous value: -"Kind-specific fields. persona: name, slug, wants, convincedBy (list), objections (list). pillar: name, slug, formats (list), notes. angle: name, slug, personaId, pillarId. Lists and notes are optional on create. market: name, country (ISO code such as US), timezone (IANA, such as America/New_York), priority (lower comes first; optional on create), locationCode and languageCode (from list_market_locations; null clears them). buyer_question: question, topic (optional; a short label, max 60 characters; empty clears it). kpi_target: metric (posts_per_week | impressions | engagement_rate | leads | qualified | rejection_rate | cost_per_lead), month (YYYY-MM), value (zero or more, up to 4 decimal places; engagement_rate in percent, so 4.5 means 4.5%)."New value: +"Kind-specific fields. persona: name, slug, wants, convincedBy (list), objections (list; put the answer in the line as objection: answer), pains (list), jobs (list: jobs to be done), language (list: phrases the customer uses, in their words). pillar: name, slug, formats (list), notes. angle: name, slug, personaId, pillarId. Lists and notes are optional on create. market: name, country (ISO code such as US), timezone (IANA, such as America/New_York), priority (lower comes first; optional on create), locationCode and languageCode (from list_market_locations; null clears them). buyer_question: question, topic (optional; a short label, max 60 characters; empty clears it). kpi_target: metric (posts_per_week | impressions | engagement_rate | leads | qualified | rejection_rate | cost_per_lead), month (YYYY-MM), value (zero or more, up to 4 decimal places; engagement_rate in percent, so 4.5 means 4.5%)."

Changed3 schema fields changedOct 8, 2026

changedInput schema / properties / fields / description

Previous value: -"Kind-specific fields. persona: name, slug, wants, convincedBy, objections. pillar: name, slug, formats, notes. angle: name, slug, personaId, pillarId. market: name, country, timezone, priority (locationCode and languageCode optional). buyer_question: question, topic (optional). kpi_target: metric, month, value."New value: +"Kind-specific fields. persona: name, slug, wants, convincedBy (list), objections (list). pillar: name, slug, formats (list), notes. angle: name, slug, personaId, pillarId. Lists and notes are optional on create. market: name, country (ISO code such as US), timezone (IANA, such as America/New_York), priority (lower comes first; optional on create), locationCode and languageCode (from list_market_locations; null clears them). buyer_question: question, topic (optional; a short label, max 60 characters; empty clears it). kpi_target: metric (posts_per_week | impressions | engagement_rate | leads | qualified | rejection_rate | cost_per_lead), month (YYYY-MM), value (zero or more, up to 4 decimal places; engagement_rate in percent, so 4.5 means 4.5%)."

addedOutput schema / properties / appUrl
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "item",
-  "kind"
-]New value: +[
+  "appUrl",
+  "item",
+  "kind"
+]

Changed1 schema field changedOct 8, 2026

changedInput schema / properties / fields / description

Previous value: -"Kind-specific fields. persona: name, slug, wants, convincedBy, objections. pillar: name, slug, formats, notes. angle: name, slug, personaId, pillarId. market: name, country, timezone, priority (locationCode and languageCode optional). buyer_question: question. kpi_target: metric, month, value."New value: +"Kind-specific fields. persona: name, slug, wants, convincedBy, objections. pillar: name, slug, formats, notes. angle: name, slug, personaId, pillarId. market: name, country, timezone, priority (locationCode and languageCode optional). buyer_question: question, topic (optional). kpi_target: metric, month, value."

First observedOct 1, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations give idempotentHint=true and destructiveHint=false, and the description layers on real behavior beyond that: slug immutability for pillar/angle, KPI month/metric immutability, KPI target active refusal, and buyer-question firstCheck return contents. Strong contextual disclosure; missing retry/permission semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense wall of text covering six kinds, running to hundreds of words with abrupt jumps between persona, market, KPI, and buyer-question info. Front-loading exists but readability and scannability suffer; much of this belongs in schema or linked docs.

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

Completeness5/5

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

Given the six-entity scope, mutation semantics, output schema presence, and 4 parameters, the description covers almost everything an agent needs: creation vs update, immutability rules, deactivation flow, return value (appUrl), and related tools. Complete for the task.

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

Parameters3/5

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

Schema coverage is 100%, so per policy the baseline is 3. The description does reinforce some semantics (personaId+pillarId come from get_brand_context, metric/month cannot change, engagement_rate is percent) that add marginal value, but the schema already documents these fields in detail.

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

Purpose4/5

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

States a clear verb+resource ('Creates or updates one strategy item') and enumerates the six kinds, distinguishing it from sibling save_* tools. It is somewhat sprawling across six different entities, which blurs focus, but each is defined in place.

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

Usage Guidelines4/5

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

Rich routing guidance: 'to add one from a place name, set_up_market resolves the codes for you', point to suggest_buyer_questions and get_content_performance, and explicit when-to-use-id vs omit-id. Lacks explicit when-not-to-use framing but alternatives are named.

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

All Mark tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?