Skip to main content
Glama

Set CAC strategy

set_cac_strategy
Destructive

Change this company's LTV:CAC strategy (the acquisition-spend posture): aggressive (2:1, early-stage growth), standard (3:1, recommended default), conservative (4:1, high churn / mature), or enterprise (5:1, long sales cycles). This governs marketing spend, so it is gated: an autonomous agent CANNOT apply it — surface a recommendation instead. Always call get_cac_strategy first and include a clear rationale when proposing a change.

[sensitive-tier — first use may require a manager's approval; a from-now-on approval makes future calls seamless, a just-once approval re-asks next time. Call it on the first clear ask; the card is the yes — do not re-ask in chat.]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoOptional rationale for the change (stored with the policy).
strategyYesThe CAC posture: aggressive (2:1), standard (3:1), conservative (4:1), or enterprise (5:1).
companyIdYesFreedomOS company id to act within (you must be a member). Required for company-scoped tools.
ads_account_idNoOptional Meta ad account the budget measures (act_<digits>, from list_ad_accounts) — required once when the Meta connection carries several accounts. Omit to leave unchanged.
monthly_ads_budgetNoOptional monthly ads budget in USD (major units, e.g. 500 = $500/month). Pass 0 to clear. Advisory envelope shown on the dashboard beside live MTD ad spend. Omit to leave unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / ads_account_id
      Added value: +{
      +  "description": "Optional Meta ad account the budget measures (act_<digits>, from list_ad_accounts) — required once when the Meta connection carries several accounts. Omit to leave unchanged.",
      +  "type": "string"
      +}
    • addedInput schema / properties / monthly_ads_budget
      Added value: +{
      +  "description": "Optional monthly ads budget in USD (major units, e.g. 500 = $500/month). Pass 0 to clear. Advisory envelope shown on the dashboard beside live MTD ad spend. Omit to leave unchanged.",
      +  "type": "number"
      +}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark destructiveHint=true, but the description adds critical behavioral nuance beyond that: the change is gated, approval tiers behave differently (from-now-on vs. just-once), and the first clear ask should trigger the approval card without re-asking. It also explains why the tool is sensitive by noting it governs marketing spend.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: action and options first, then gating and prohibition, then required pre-call and rationale, then approval-card behavior. The parenthetical about approval modes is technical but directly actionable for an agent.

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?

For a destructive, gated mutation tool with no output schema, the description covers what matters most: what the tool changes, which values are allowed, when not to invoke it autonomously, what to do first, what to include as rationale, and how approvals behave. Nothing essential is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all parameters well. The description still adds meaning by attaching business context to strategy values (e.g., aggressive = early-stage growth, standard = recommended default, enterprise = long sales cycles), which helps an agent select the right enum value. It does not add much for ads_account_id or monthly_ads_budget, but those are already fully specified in the schema.

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

Purpose5/5

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

The description opens with a specific verb and resource: "Change this company's LTV:CAC strategy," followed by the four concrete strategy options with their ratio meanings. It also clearly differentiates itself from the sibling get_cac_strategy by framing this as the mutation counterpart to that read operation.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use and when-not-to-use guidance: it says an autonomous agent CANNOT apply the change and should surface a recommendation instead. It also mandates a sequencing step ("Always call get_cac_strategy first"), requires a rationale, and explains the approval-card flow so the agent knows not to re-ask.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources