Skip to main content
Glama

Record a boost's numbers

boost_record

Record what the platform's Ads Manager shows for a boost, read in the founder's Chrome: per post or ad (n, the ad group's or ad set's number in the plan; a split boost per ad group, with device desktop or phone) the spend in USD (an account billing in another currency: converted at today's rate), impressions, and link clicks, not all clicks (engagements for a reach boost). status running when the founder has pressed Launch or Publish, stopped when they stop it. Reddit and Google, where your browser cannot go: pass the founder's export as csv (Reddit Ads, Reports, by ad group, Export; Google Ads, Campaigns, Download) and the server reads each ad group named "ad ", or Google campaign named sf-boost-- (spend or cost, impressions, clicks; daily rows added up), with usdRate when the account bills in another currency; numbers in posts win over it. Never invent a number: leave out what you could not read. Free.

Input Schema

NameRequiredDescriptionDefault
idYes
csvNoThe Ads Manager export, pasted as it is, broken down by ad group
postsNo
statusNo
usdRateNoUSD per unit of the account's currency, for the export's spend; default 1

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / posts / items / properties / device
      Added value: +{
      +  "description": "A split boost's ad group: ad <n> desktop or ad <n> phone",
      +  "enum": [
      +    "desktop",
      +    "phone"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / posts / maxItems
      Previous value: -3New value: +6
  2. Changed2 schema fields changed
    • addedInput schema / properties / csv
      Added value: +{
      +  "description": "The Ads Manager export, pasted as it is, broken down by ad group",
      +  "maxLength": 100000,
      +  "type": "string"
      +}
    • addedInput schema / properties / usdRate
      Added value: +{
      +  "description": "USD per unit of the account's currency, for the export's spend; default 1",
      +  "type": "number"
      +}
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive, closed-world write, and the description adds genuine operating rules on top: never invent a number, omit what could not be read, convert foreign billing at today's rate, and statuses derive from the founder pressing Launch/Publish or stopping. It does not say whether previously recorded numbers are replaced or merged, which is the main behavioral gap for a write tool.

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

Conciseness3/5

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

Purpose is front-loaded, but the body is a single run-on chain of semicolons and parentheticals that is dense to parse on first read. Almost every clause carries real information, yet the CSV and currency rules could be split into separate sentences for scanability.

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

Completeness4/5

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

For a 5-parameter ingest tool with no output schema and only 40% schema documentation, the description covers both input sources, currency handling, and the no-fabrication rule. What it leaves out is the write semantics against existing records (overwrite vs. append) and any hint of what the call returns.

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

Parameters5/5

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

Schema coverage is only 40%, and the description compensates thoroughly: it defines `n` as the ad group's/ad set's number in the plan, explains `device` for split boosts, distinguishes link clicks from all clicks (engagements for reach boosts), documents the CSV shape including the 'ad <n>' and 'sf-boost-<id>-<n>' naming conventions and daily-row summing, and clarifies `usdRate` semantics with its default.

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 first clause names a specific verb and resource — record the Ads Manager numbers for a boost — and then enumerates exactly which metrics (spend USD, impressions, link clicks) and for which unit (post/ad, ad group, split-by-device). It is clearly distinguishable from boost_plan (planning) and boost_results (reporting), since this is the ingest step.

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?

It gives explicit routing: read from the founder's Chrome for Meta-style boosts, and pass a CSV export for Reddit/Google 'where your browser cannot go', naming the exact export path in each platform's UI. It also states precedence (numbers in posts win over csv). It does not name sibling tools such as boost_results or boost_plan as alternatives, so it falls short of a true 5.

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