Skip to main content
Glama
getsimba-ai

Simba MCP Server

Official
by getsimba-ai

List Campaigns

list_campaigns
Read-onlyIdempotent

Retrieve campaign totals and channel mappings for a specific model, including unmapped campaigns. Use to audit which campaigns count toward each channel.

Instructions

List the campaigns in the campaign facts, each with its totals and the model channel it counts towards for this model.

The channel is DECLARED in the model's campaign map (set_campaign_mapping), never inferred: a campaign no map row covers is status: "unmapped" with channel: null, is listed with its spend, and is not counted towards any channel. suggested_channel is a hint from the platform's own label and the campaign's name (null when nothing is clear); it does nothing until it is written into the map.

Returns {campaigns: [{platform, account_id, campaign_id, campaign_name, adsets, spend, impressions, clicks, platform_conversions, platform_value, platform_channel_type, first_seen, last_seen, channel, suggested_channel, status: "mapped" | "unmapped"}], window: {start, end}, currency, as_of, next_cursor (only when limit was given)}. Sorted by platform, account and campaign id. Totals cover the window (default: every stored day).

Args: model_hash: The model whose map decides each campaign's channel (the hash of a fitted MMM). platform: Keep one platform: meta, google_ads, tiktok or other. unmapped_only: Only campaigns without a channel for this model. start, end: Optional ISO dates (YYYY-MM-DD), inclusive, for the totals. limit: Page size (1-200). Without it every campaign is returned. cursor: The previous page's next_cursor.

Errors carry a code: model_not_found (404). An empty list means no pipeline is registered as the campaign facts source yet, or it has not run; registration happens in the app.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNo
limitNo
startNo
cursorNo
platformNo
model_hashYes
unmapped_onlyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.14.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover read/idempotent/destructive safety, but the description adds pagination behavior (next_cursor only when limit is given), sort order, default window ('every stored day'), the meaning of an empty result, and the model_not_found error code — all beyond structured data.

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?

Front-loaded and dense, but the detailed Returns block is redundant given an output schema exists, making it longer than strictly necessary. Still, the prose mostly earns its place through channel/status semantics not documented elsewhere.

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 filtered, paginated read with an output schema, the description covers every arg, the channel-resolution model, pagination, empty-state cause, and errors. Nothing an agent needs to invoke it correctly is missing.

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 0%, so the description must carry the full parameter burden — and it does, documenting every arg including model_hash semantics, platform enum values, unmapped_only, inclusive ISO start/end, limit range, and cursor. Excellent compensation for the coverage gap.

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?

States a specific verb (list) and resource (campaigns) with scope: campaign facts, totals, and the model channel. The channel-semantics explanation ('declared in the model's campaign map, never inferred') makes clear how this differs from a plain report tool like get_campaign_report.

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?

Explains when unmapped campaigns appear and that set_campaign_mapping is what assigns channels, giving the agent solid context. However, it never states when to prefer this over sibling report tools such as get_campaign_report or get_campaign_incrementality.

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

Deploy Server

Other Tools