How to connect AirOps MCP with Codex

Add a region (ISO alpha-2 country code) to a Brand Kit's configured AEO regions. Why this tool exists: AEO prompts and prompt-assignments can only reference regions that are configured on the Brand Kit. When `create_aeo_prompt` or `update_aeo_prompt_assignments` returns a `validation_error` mentioning that the country code is "not configured on this brand kit", call this tool to add the missing region first, then retry. Behavior: - Re-adding an already-configured region is a no-op (idempotent) and returns success. - The country code must be a valid ISO 3166-1 alpha-2 code supported by the platform (e.g. US, GB, DE, FR, JP, BR, IN, ...). - Optional `add_to_all_prompts` (default `false`): when `true`, the new region is also assigned to every existing live prompt in the Brand Kit. This may incur additional answer credits/month; if the workspace's estimated answers limit would be exceeded, the call is rejected with a `validation_error` containing `estimated_answers` and `max_answers` in `details`. Defaults to `false` so the agent does not silently incur credits. IMPORTANT: Always show the user the region you plan to add (and whether `add_to_all_prompts` is on) and get explicit confirmation before calling. Adding a region cannot be undone via this tool.

Get one ad observed in ChatGPT answers. The 'id' parameter is the observed_creative_id returned by list_aeo_ads.

List ads observed in ChatGPT answers for a Brand Kit. Ads observed by AirOps in collected ChatGPT answers. Rows are unique ads: observations sharing the same normalized creative are grouped into one, with appearance counts describing how often that ad was observed. Covers ads AirOps has seen in its own answer collection, so it does not describe full market coverage, targeting intent, impression delivery, or advertiser spend.

List saved analytics reports for a specific Brand Kit. Reports are saved analytics views for a Brand Kit. They contain modules that display different analytics metrics.

Get a specific report by ID with its module configurations. Reports are saved analytics views for a Brand Kit. They contain modules that display different analytics metrics.

Create a grid pre-wired with power steps to take action on AEO insights. This is the ONLY supported way to run power steps from MCP: each action_type maps to a specific set of power step columns (e.g. content optimization, citation outreach, question answering) that are auto-configured on the grid and ready to execute against the rows you provide. Use this whenever the user wants to act on AEO data — citations, questions, page opportunities, etc. — for a specific brand kit; pass the AEO records as `rows` and the matching `action_type`. Do NOT use create_grid + add_grid_column to assemble a power step grid by hand; that path will not produce a working power step setup. Use create_grid only for empty, general-purpose grids unrelated to AEO.

List advertisers observed in ChatGPT answers for a Brand Kit. Advertisers observed by AirOps in collected ChatGPT answers. Rows roll up every observed ad to the advertiser that ran it, identified by canonical domain. Covers ads AirOps has seen in its own answer collection, so it does not describe full market coverage, targeting intent, impression delivery, or advertiser spend. Use list_aeo_ads for the individual ads behind these counts.

List page content updates for a workspace. Track content updates.

Get a specific page content update by ID. Its change_detection object carries the detection status and categories, plus a nested changes array (the before/after diff) on this single-update fetch. Track content updates.

Track a page content update (publish/refresh) to correlate future analytics with content changes. Call this tool after a page is published or refreshed through a CMS (e.g. WordPress, Webflow, Contentful) or any MCP server that modifies page content. This lets AirOps correlate page performance metrics — AI visibility, citations, mentions — with specific content updates over time. The URL must match a domain configured in one of the workspace's Brand Kits. If no matching Brand Kit domain is found, the content update cannot be created. If the URL matches multiple Brand Kits (for example regional variants sharing a domain), a content update is created for each, routed by the most specific brand_url path (e.g. "https://example.com/es/post" maps to the Brand Kit whose brand_url is "https://example.com/es/"). IMPORTANT: Always show the user exactly which fields you plan to use (url, type, source) and ask for their confirmation before calling this tool. User confirmation is mandatory.

List personas for a specific Brand Kit. Personas are the characters that can be used to ask questions about a brand. They are used to get AI answers with citations and mentions.

Create a new AEO persona on a Brand Kit. Personas represent the characters used to simulate AI-search queries when measuring AI visibility, citations, and mentions. Behavior: - `title` must be unique within the Brand Kit (max 200 chars) and `description` is required (max 5000 chars). - Optional `add_to_all_prompts` (default `false`): when `true`, the new persona is also assigned to every existing live prompt in the Brand Kit. This may incur additional answer credits/month; if the workspace's estimated answers limit would be exceeded, the call is rejected with a `validation_error` containing `estimated_answers` and `max_answers` in `details`. Defaults to `false` so the agent does not silently incur credits. Writing guidance: avoid including specific brand names in the persona's title or description — the LLM may then mention the brand in its answer, which the analyzer will count as a mention and skew the data. IMPORTANT: Always show the user the persona you plan to create (title, description, and whether `add_to_all_prompts` is on) and get explicit confirmation before calling. You can verify the persona was created by calling `list_personas` sorted by `created_at` descending.

Get prompts citing a specific URL. The 'id' parameter is the URL to look up.

List citations (URLs) with metrics for a Brand Kit. Citations (URLs) with detailed metrics including influence score. Shows individual URLs being cited in AI answers with page-level context.

List domains cited in AI answers for a Brand Kit. Cited domains aggregated by domain with citation metrics. Shows which domains are being cited in AI answers for a Brand Kit.

Apply a single tag operation (add or remove) to a batch of AEO prompts in one Brand Kit, atomically. Operations: - `add` — adds the supplied tag_ids to each prompt's existing tags. Duplicates are silently deduped. - `remove` — removes the supplied tag_ids from each prompt. Tags not currently on a prompt are silently no-oped. Specifying tags: - Pass `tag_ids` (use `list_tags` to discover them). - Tags must already exist on the Brand Kit. This tool does NOT create new tags. Atomicity: - The call is fully atomic. If ANY supplied `prompt_id` is missing/discarded/ cross-brand-kit, or ANY `tag_id` is unknown on the Brand Kit, the call is refused with a `validation_error` listing every problem, and no taggings are changed. - On success, all listed prompts receive the operation in a single DB transaction. Limits: - Up to 100 `prompt_ids` per call. IMPORTANT: Always show the user the prompts and tags you plan to operate on, and get explicit confirmation before calling.

Query analytics data and display it as an interactive chart. Returns data with a UI reference for visualization. Today's data is still being processed — always use yesterday (2026-09-21) or earlier as end_date. CONSTRAINTS: (1) Only metrics from the same scale group can be plotted together: percentage metrics (mention_rate, positive_answer_rate, share_of_voice, citation_rate, citation_share, sentiment_score, first_mention_rate), count metrics (citation_count, answer_count), or position metrics (average_position). (2) Area and bar charts support only single metrics with single dimensions. (3) Line charts support up to 2 dimensions (date + optional grouping), but when using 2 dimensions only a single metric is allowed.

Query analytics data for a Brand Kit with flexible metrics, dimensions, and filters. Today's data is still being processed — always use yesterday (2026-09-21) or earlier as end_date . "Use this to set appropriate date ranges when users ask about recent metrics without specifying dates. IMPORTANT: USE chart_image_url WHEN YOU NEED TO EMBED A CHART IN NOTION/GOOGLE DOCS, ETC."

Update the country, persona, and platform assignments of one or more existing AEO prompts on a Brand Kit. Writes to the brand kit's draft session ONLY — changes do NOT take effect until you call `commit_aeo_prompt_assignments`. Semantics: - For each entry in `prompts`, a non-empty array REPLACES that prompt's current draft assignments for the given dimension. - An empty array CLEARS that dimension on the prompt. - Omitting a dimension or passing null leaves that dimension UNCHANGED. - At most 100 prompts can be updated per call. Workflow: 1. Call `update_aeo_prompt_assignments` to stage your changes in the draft. 2. Inspect `limit_exceeded` in the response. If true, the workspace would exceed its estimated-answers quota on commit. Adjust by calling `update_aeo_prompt_assignments` again, or call `discard_aeo_prompt_assignments` to abandon. 3. When ready, call `commit_aeo_prompt_assignments` to apply the draft to live. Always confirm with the user before committing. IMPORTANT — shared draft with the UI: - There is one draft per brand kit, shared between MCP and the human-facing UI. - If the user has unsaved UI edits, your edits accumulate in the same draft. A subsequent commit will publish both sets of edits together; a discard will destroy both. Surface this to the user before committing or discarding. To discover prompt IDs and current assignments, use `list_aeo_prompts`. To inspect current draft state without modifying it, use `get_aeo_prompt_assignments_status`.

Commit the current prompt-assignment draft for a Brand Kit to live. Replaces all live country, persona, and platform assignments for the brand kit's prompts with the draft data. The workspace's estimated answers limit is enforced. If committing would push the workspace over its quota, the call is rejected with an `AnswersLimitExceeded` validation error containing `estimated_answers` and `max_answers` in `details`. Recover by calling `update_aeo_prompt_assignments` to adjust, or `discard_aeo_prompt_assignments` to abandon. IMPORTANT: - This action affects live data and is not undoable except by manually editing assignments again. Always get explicit user confirmation before calling. - If the human user has unsaved UI edits in the same draft, those will also be committed. Surface this to the user before proceeding. - After a successful commit, a fresh empty draft is automatically re-mirrored from the new live data. You may immediately stage further edits with `update_aeo_prompt_assignments`. - This tool does NOT return the new live estimated-answers/month. If you or the user need the post-commit estimates, call `get_aeo_prompt_assignments_status`. Do NOT reuse the pre-commit `draft_estimated_answers` from `update_aeo_prompt_assignments` and do NOT compute the estimate yourself — repetition-times, persona/country/platform interactions, and concurrent edits can all shift the result.

Discard the current prompt-assignment draft for a Brand Kit. Throws away ALL uncommitted edits — both your own and any unsaved edits the human user made in the UI — and re-mirrors a fresh empty draft from live. Live assignments are never touched. IMPORTANT: - This action is destructive and unrecoverable. Pending UI edits the user has not committed will be lost. - Always get explicit user confirmation before calling. - Calling discard when no draft exists is a no-op; a fresh empty draft is still created so further `update_aeo_prompt_assignments` calls work without setup.

Inspect the current prompt-assignment draft state for a Brand Kit without modifying anything. Read-only. This is the authoritative source for workspace estimated-answers numbers (live and draft). Call it whenever you need them — never compute or guess them yourself. In particular: - At the start of a session, to detect a pre-existing draft from unsaved UI edits. - Immediately after `commit_aeo_prompt_assignments`, to read the new live `estimated_answers` — the commit tool does not return them. - Before staging more changes via `update_aeo_prompt_assignments`, to compare against `max_answers`. Returns: - `has_draft`: whether a draft session exists for this brand kit. - `has_changes`: whether the draft has uncommitted edits relative to live (null if no draft). - `draft_id`: the draft's ID (null if no draft). - `live_estimated_answers`: current workspace estimated answers/month based on live assignments. - `draft_estimated_answers`: what the workspace estimated answers/month would be if the draft were committed now (null if no draft). - `max_answers`: the workspace's effective answers limit. - `limit_exceeded`: whether committing the draft now would exceed the limit (false if no draft).

Get individual AI answers with sentiment details for a specific theme. Returns answer text, sentiment (positive/neutral/negative), confidence score, and provider. Use this to understand WHY a theme has a particular sentiment score. Today's data is still being processed — always use yesterday (2026-09-21) or earlier as end_date.

List topics for a specific Brand Kit. Topics are the categories of questions that can be asked about a Brand Kit. They are used to group questions together and to create a taxonomy of questions.

Create a new AEO topic on a Brand Kit. Topics are categories used to group AEO prompts. Behavior: - `name` must be unique within the Brand Kit. - `color` is optional. If omitted, a color is auto-assigned from the platform palette. Valid colors: light_grey, grey, green, teal, blue, purple, lilac, pink, red, coral, orange. - This tool does NOT create or assign prompts. Use `create_aeo_prompt` with the returned topic ID to add prompts to the topic. IMPORTANT: Always show the user the topic you plan to create (name and color) and get explicit confirmation before calling. You can verify the topic was created by calling `list_topics` filtered by name.

Update an existing AEO topic's name and/or color on a Brand Kit. Behavior: - At least one of `name` or `color` must be provided. - If `name` is provided, it must remain unique within the Brand Kit. - Valid colors: light_grey, grey, green, teal, blue, purple, lilac, pink, red, coral, orange. - Existing prompt assignments are preserved. This tool cannot move a topic to another Brand Kit. IMPORTANT: Always show the user the topic (current name) and the change you plan to apply, and get explicit confirmation before calling. You can verify the change by calling `list_topics`.

Delete an AEO topic from a Brand Kit. Behavior: - This is a HARD delete. The topic is removed from the Brand Kit entirely. - Deletion is blocked when the topic has associated prompts. Use `list_aeo_prompts` filtered by `topic_id` to inspect prompts before deleting. - Candidate questions and question recommendations for the topic are deleted by model associations when the topic is deleted. IMPORTANT: This action is destructive and cannot be undone via this tool. Always show the user the topic name and associated prompt count, then get explicit confirmation before calling.

List tags for a specific Brand Kit. Tags are user-defined labels applied to prompts within a Brand Kit. They are typically used to filter analytics by arbitrary groupings (e.g. priority, campaign, theme) that go beyond topics.

Create a new AEO tag on a Brand Kit. Tags are user-defined labels that can be applied to prompts via `bulk_update_aeo_prompt_tags`. Behavior: - `name` must be unique within the Brand Kit (case-insensitive). The model enforces this via a unique index on (brand_kit_id, lower(name)). - `color` is optional. If omitted, a color is auto-assigned from the platform palette. Valid colors: light_grey, grey, green, teal, blue, purple, lilac, pink, red, coral, orange. - This tool does NOT apply the new tag to any prompts. Use `bulk_update_aeo_prompt_tags` with `operation: 'add'` to assign it afterward. IMPORTANT: Always show the user the tag you plan to create (name and color) and get explicit confirmation before calling. You can verify the tag was created by calling `list_tags` filtered by name.

Update an existing AEO tag's name and/or color on a Brand Kit. Behavior: - At least one of `name` or `color` must be provided. - If `name` is provided, it must remain unique within the Brand Kit (case-insensitive). - Valid colors: light_grey, grey, green, teal, blue, purple, lilac, pink, red, coral, orange. - Existing taggings on prompts are preserved — only the tag's own attributes change. IMPORTANT: Always show the user the tag (current name) and the change you plan to apply, and get explicit confirmation before calling. You can verify the change by calling `list_tags`.

Delete an AEO tag from a Brand Kit. Behavior: - This is a HARD delete. The tag is removed from the Brand Kit entirely. - All taggings on prompts that referenced this tag are also deleted (cascade via `Aeo::Tag has_many :taggings, dependent: :destroy`). Every prompt that had this tag will lose it. - The response includes `tagged_prompts_count`: the number of prompts that lost the tag. Use this to communicate the blast radius back to the user. IMPORTANT: This action is destructive and cannot be undone via this tool. Always show the user the tag name AND `tagged_prompts_count` (look it up first via `list_tags` + `list_aeo_prompts` if needed) and get explicit confirmation before calling.

List AEO prompts for a specific Brand Kit. Questions are the AI prompts that can be asked about a brand. They are used to get AI answers with citations and mentions.

Create a new AEO prompt for a Brand Kit. Prompts are questions that can be asked about a brand to AI search engines, used to track AI visibility and citations. After creation, background jobs automatically analyze the prompt on search engines, extract keywords, and compute volume metrics. You can optionally assign countries, personas, and platforms to the prompt at creation time. The workspace's estimated answers limit is enforced — if the assignments would push the workspace over its quota, creation is rejected. IMPORTANT: Always show the user exactly which fields you plan to use (text, topic_id, and any assignments) and ask for their confirmation before calling this tool. User confirmation is mandatory. You can verify the prompt was created by calling `list_aeo_prompts` sorted by `created_at` descending. A topic_id is required. If the user hasn't specified a topic, use the `list_topics` tool first to discover available topics and either suggest one or ask the user to choose.

Delete an AEO prompt from a Brand Kit. Use `list_aeo_prompts` to find the prompt ID and verify the prompt text before deletion. IMPORTANT: This action is destructive. Always show the user the exact prompt text and get explicit confirmation before calling this tool.

Reassign a batch of AEO prompts to an existing topic in one Brand Kit. Specifying the destination topic: - Pass `topic_id` (use `list_topics` to discover them). - The topic must already exist on the Brand Kit. This tool does NOT create topics. To create a new topic first, use `create_topic`, then pass its id here. Specifying prompts: - Pass `prompt_ids` (use `list_aeo_prompts` filtered by `topic_id` to find prompts currently under a source topic). - IDs that are missing, discarded, or not in the Brand Kit are skipped; only matching prompts are updated. IMPORTANT: Always show the user the prompts and destination topic you plan to operate on, and get explicit confirmation before calling.

Add a web page to a Brand Kit's AEO pages. The URL is normalized before the page is created, and the page is associated with the Brand Kit's configured AEO domain. The URL must be unique within the Brand Kit. IMPORTANT: Always show the user the URL and Brand Kit you plan to use and get explicit confirmation before calling this tool. You can verify the page was created by calling `list_pages` filtered by URL.

List campaigns the authenticated user has access to. Use get_campaign to retrieve action grid IDs and custom instructions for a campaign. Campaigns are Plays that coordinate strategy playbooks, action grids, and related opportunities for improving AEO performance.

Get a campaign by ID, including action grid IDs needed to inspect or update its grid. Campaigns are Plays that coordinate strategy playbooks, action grids, and related opportunities for improving AEO performance.

List opportunities for a campaign. V1 responses include matching opportunity items; v2 responses include parent review state, the target page, and ordered contexts.

Create one pending opportunity for a Campaign. In interactive Quill or OAuth sessions, summarize the proposed name, description, and target resources and get explicit confirmation first. Campaign strategy Playbooks infer their own Campaign. Other Playbooks must provide play_id, inspect existing Opportunities before creating more, and may create pending Opportunities without interactive confirmation when the Campaign write feature is enabled. For page_refresh, page_creation, and youtube_engagement Campaigns, read the matching Opportunity rationale skill and pass its complete Markdown brief unchanged in description.

Accept pending opportunities for a campaign and add them to the campaign action grid. For v2 campaigns, pass opportunity_ids; acceptance uses the original rationale and every opportunity context. Before calling this tool, summarize the opportunities or opportunity items that will be accepted and get explicit user confirmation.

Reject pending opportunities for a campaign. For v2 campaigns, pass opportunity_ids; opportunity item selection and rejection reasons are v1-only. Before calling this tool, summarize the opportunities or opportunity items that will be rejected and get explicit user confirmation.

Initiate a direct file upload for a Knowledge Base. Returns a presigned S3 upload URL, the required upload headers, and a `signed_id` you'll use with `knowledge_base_add_file` to register the document. This is the first call in the two-step file ingestion flow — large files (PDFs, DOCX, MD, HTML, etc.) don't fit through the MCP transport, so the file bytes go directly from your client to S3. Workflow: 1. Call this tool with the file metadata (filename, content_type, byte_size, checksum). The checksum must be the Base64-encoded MD5 digest of the file contents. 2. PUT the raw file bytes to the returned `upload_url` with **all** the provided `upload_headers`. No additional authentication is needed — the URL is a time-limited presigned URL. 3. Pass the returned `signed_id` to `knowledge_base_add_file` to register the document. Only after step 3 is the file searchable. Example: > knowledge_base_create_direct_upload(knowledge_base_id: 1, filename: "report.pdf", content_type: "application/pdf", byte_size: 1234567, checksum: "...") # → { signed_id: "abc...", upload_url: "https://s3...", upload_headers: { ... } } > knowledge_base_add_file(knowledge_base_id: 1, signed_id: "abc...", name: "Q4 Report", document_type: "application/pdf") # → { document_ids: [42], status: "pending" } Maximum file size is 256 MB.

Permanently delete a single document from a Knowledge Base. This action cannot be undone. IMPORTANT: Always warn the user that deletion is permanent and ask for explicit confirmation before calling this tool.

Read the full reconstructed text content of a Knowledge Base document end-to-end — the loader-extracted text from every chunk concatenated in `position` order. Use when chunked search results aren't enough: summarizing a whole document, answering questions across an entire report, or reading back a doc before delete-and-recreate. For finding specific passages, prefer `search_knowledge_base`. Returns up to `max_chars` characters starting at `offset` (defaults to 0 and 200000). When the document is larger than the slice, the response includes `next_offset` (the value to pass on the next call to continue reading); when fully read, `next_offset` is `null`. For documents still indexing (`status: pending`) or in error (`status: error`), content may be empty — check `status` first. Content is reconstructed by joining chunks; minor overlap or duplication between adjacent chunks is possible depending on the original loader's chunking strategy. For the original source file, use the existing download path outside MCP.

Get the indexing status of a Knowledge Base and its documents. Returns a Knowledge Base–level rollup (status, pending and total document counts) plus a paginated list of per-document statuses. Use this to monitor indexing after writes — only documents with status "ready" are returned by search_knowledge_base. Pass the returned `cursor` back to fetch the next page; pass `document_ids` to filter to specific documents.

Create or update a Knowledge Base. Omit `knowledge_base_id` to create a new one; pass it to update an existing one. On create, `name` is required; pass `workspace_id` if you have access to more than one workspace. On update, only the fields you pass change.

Replace a document's user-facing metadata in full. Accepts a single-level hash that **replaces** (not merges) the existing user-facing metadata. To remove a key, pass the full new hash that omits it. To clear all metadata, pass `{}`. Filterable at search time via `search_knowledge_base`. Metadata-only — does not re-embed the document. Loader-derived metadata (scraped page metadata for URLs, chunker metadata for files) is not touched. Search filters may take a few seconds to reflect the new values. The document must be fully indexed (`status: ready`) before calling this tool. If indexing isn't complete, the tool returns a validation error.

Permanently delete a Knowledge Base and ALL of its documents. This cascades through every document in the KB and drops the underlying vectors. This action cannot be undone. IMPORTANT: Always warn the user that deletion is permanent and irreversible, name the Knowledge Base being deleted, and ask for explicit confirmation before calling this tool.

Search a Knowledge Base for relevant content using semantic similarity. Use list_knowledge_bases() first to find available Knowledge Bases and their IDs. Only Knowledge Bases with status "ready" can be searched.

List all Knowledge Bases the authenticated user has access to. Knowledge Bases store documents for semantic search. Use the status field to determine if a Knowledge Base is searchable (status: "ready").

Step 2 of the two-step file ingestion flow for a Knowledge Base. Consumes a `signed_id` returned by `knowledge_base_create_direct_upload` (step 1) plus the file's metadata, and registers the document with the Knowledge Base. Returns immediately with the new `document_id` in `pending` status — poll `knowledge_base_get_status` to monitor indexing. Workflow: 1. Call `knowledge_base_create_direct_upload` with the file metadata to get back a `signed_id` and a presigned `upload_url`. 2. PUT the file bytes to the `upload_url` with the provided headers. 3. Call this tool with the `signed_id`, the desired `name` (used as the document's display name), the `document_type` MIME (must match the supported types), and an optional `metadata` hash. The `metadata` hash, if provided, is a single-level key/value object. It **replaces** any existing metadata on the document (no merge) and is filterable at search time via `search_knowledge_base`.

Bulk-ingest one or more web pages into a Knowledge Base. Each URL becomes a separate document that fetches and indexes asynchronously. The call returns immediately with the new document IDs in `pending` state — poll `knowledge_base_get_status` to check progress. URLs must be absolute and include the `http://` or `https://` scheme (e.g. `https://example.com/page`). No documents are created if any URL fails validation. The `metadata` hash, if provided, is applied identically to every document in the batch (single-level keys only); it replaces (not merges) any existing metadata and is filterable at search time.

List all Brand Kits the user has access to. Returns `brand_management_enabled` and `aeo_enabled` flags for each brand kit. Use `get_brand_kit` for brand management details, or `get_insights_settings` for AEO configuration. Optionally filter by workspace_name, workspace_id, brand_management_enabled, or aeo_enabled. IMPORTANT: If multiple brand kits are returned and the user has not specified which one to use, present the list and ask them to confirm. Do NOT arbitrarily pick one.

Fetch a Brand Kit's brand identity (writing_tone, writing_persona) and associated entities (product lines, audiences, content types, regions, writing rules, custom variables, visual/design assets). Call AFTER `list_brand_kits` confirms `brand_management_enabled: true`. # Decision flow 1. Specific entity by ID → `includes=["<type>"]`, `filters=[{field: "<type>.id", operator: "EQ", value: <id>}]`. 2. Entity by name (product_lines, content_types, audiences, regions, custom_variables, visual_examples) → `filters=[{field: "<type>.name", operator: "CONTAINS", value: "<fragment>"}]`. 3. Find text content ("rule about tone", "any mention of Red List") → filter by the text field: `filters=[{field: "writing_rules.text", operator: "CONTAINS", value: "tone"}]`. 4. Structural discovery → small `includes` with `fields=["<type>.id","<type>.name"]` only. # Scale (typical kit vs outliers) Most kits are small — these rarely need filtering: - audiences, regions, usage_rules, palettes, content_samples: usually 0-2, rarely >10 - content_types, product_lines: usually 1-3 These have tails you must handle: - writing_rules: usually 3, outliers exceed 200. Never include in full without a filter — filter by text (CONTAINS) or by id. - competitors: usually 10, outliers exceed 250. Include via product_lines.competitors only when needed, and consider a name filter. - custom_variables: outliers exceed 150. Filter by name (CONTAINS) for known variables (e.g. "Red List"), or by value (CONTAINS) for content. - Scoped writing_rules via audience/region/content_type nesting: outliers exceed 200. Filter the parent by id or name first. # Writing rules — global vs scoped Writing rules are EITHER global OR scoped to a single audience/content_type/region (never both). For content targeting a specific audience/region/content_type, fetch BOTH: 1. Top-level `writing_rules` include → global rules. 2. Nested writing_rules on the scoping parent → scoped rules. Merge client-side. # Anti-patterns - `includes=["writing_rules","custom_variables","product_lines.competitors", "content_types.writing_rules"]` without filters → blows context on outlier kits. - Calling without `fields` on a large kit → returns full text (template_outline, rule text, ICP) for every row. - Forgetting filters on `writing_rules`, `custom_variables`, or `competitors` — those are the three biggest tails. # Versioning `version: "draft"` reads pending edits; defaults to `"active"`. Use active for on-brand output unless the user explicitly asks for draft.

Create or update a region for a Brand Kit. Omit `id` to create a new region; provide `id` to update an existing one. On update, only provided fields are changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Before creating a custom variable, you MUST analyze the user's intent and suggest the appropriate Brand Kit dimension instead. Map the request to these alternatives first: - Region + Writing Rule: For location/language-specific instructions (e.g., "US writing tone", "UK spelling") - Audience + Writing Rule: For audience-specific guidelines (e.g., "developer tone", "enterprise style") - Content Type: For format-specific rules (e.g., "blog post structure", "email CTA") - Writing Rule (global): For general writing guidelines - Writing Tone / Writing Persona: For overall voice and style Create or update a custom variable for a Brand Kit. Omit `id` to create a new custom variable; provide `id` to update an existing one. On create, `name` and `value` are required. On update, only provided fields are changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Initiate a direct file upload for use with Brand Kit visual tools. This returns an upload URL (pointing directly to the storage service), upload headers, and a signed_id. The workflow is: 1. Call this tool with the Brand Kit ID and file metadata (filename, content_type, byte_size, checksum). The checksum must be the Base64-encoded MD5 digest of the file contents. 2. Upload the file to the returned `upload_url` using an HTTP PUT with **all** the provided `upload_headers`. No additional authentication is needed — the URL is a time-limited presigned URL. Example: curl -X PUT -H "Content-Type: <type>" -H "Content-MD5: <checksum>" --upload-file <path> "<upload_url>" 3. Pass the returned `signed_id` to a manage tool (e.g. manage_brand_kit_logo_variant, manage_brand_kit_visual_example, or manage_brand_kit_font). IMPORTANT: Always confirm with the user before initiating an upload.

Get AEO insights configuration for a Brand Kit, this includes the relevant information to use any AEO and analytics tools. Returns competitors, personas, prompt count, and other relevant information. Use `list_brand_kits` first to find Brand Kits with `aeo_enabled: true`.

Publish a Brand Kit's current draft so changes become active. This promotes the current draft to active and creates a fresh draft from it. IMPORTANT: Always confirm with the user before publishing.

Record a recap entry summarizing the changes you made to a Brand Kit. Call this once, near the end of a session that mutated the Brand Kit draft — not for every edit. Do not call this tool if you made no Brand Kit draft mutations this session (for example, you only read the Brand Kit, suggested edits the user rejected, or worked on Playbooks, Campaigns, or Insights). Never create a recap that says nothing changed. Put the evidence behind the changes in `body_markdown`: verbatim quotes, source URLs, and pages. Example: create_brand_kit_recap_entry( brand_kit_id: 123, title: "Refreshed tone & voice and added 2 regions", body_markdown: "Made the tone more concise per the latest brand guidelines (https://acme.com/brand). Added US East and US West to support the Q3 launch." )

Update a Brand Kit's base fields. Only provided fields are changed. Use get_brand_kit first to see current values. Updatable fields include brand identity (name, URL, about) and writing style (persona, tone). This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be changed and ask for confirmation before calling this tool.

Suggest edits to a Brand Kit's fields without applying them. Returns a comparison of current vs suggested values for user review. The user will see a UI to accept or reject each suggestion before changes are applied. Only include fields you want to suggest changes for. Call this tool once per entity (e.g. once per audience, once per content type). Supported entity types and their fields: - brand_kit: brand_name, brand_url, brand_about, writing_persona, writing_tone - audience: name, description - content_type: name, template_outline, cta_text, cta_url, header_case, header_case_custom_value - product_line: name, details, positioning, ideal_customer_profile, url - region: name, description, icon_name (flag code in format flag-{iso2}, e.g. flag-us, flag-gb, flag-br) - writing_rule: text, region_id (create only), content_type_id (create only), audience_id (create only) - competitor: name, domain, details, product_line_ids - content_sample: url (create only), content_type_id (create only), content (update only), audience_ids, region_ids - custom_variable: name, value - logo_variant: name, background_color, usage_instructions (to upload a logo image use manage_brand_kit_logo_variant directly with file_url) - logo_size: name, width, height, usage_instructions - font: name, usage_instructions, google_font_link, file_url (publicly accessible URL to a font file) - type_size: name, weight, size, line_height, usage_instructions - palette: name

Create or update a competitor for a Brand Kit. Omit `id` to create a new competitor; provide `id` to update an existing one. On update, only provided fields are changed. Competitors must be associated with at least one product line from the same brand kit. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a content sample for a Brand Kit. Omit `id` to create a new content sample; provide `id` to update an existing one. On create, provide either `url` (content will be extracted asynchronously) or `content` (plain text, stored immediately). On update, only `content`, `url`, `audience_ids`, and `region_ids` can be changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a content type for a Brand Kit. Omit `id` to create a new content type; provide `id` to update an existing one. On create, you may provide a `sample_url` to seed the content type with a content sample: - If only `sample_url` is provided (no content fields), the system will scrape the URL and use AI to generate all content type fields automatically. - If `sample_url` is provided along with content fields, the URL will be scraped for reference but the provided field values will be kept as-is. - If no `sample_url` is provided, the content type is created with the given fields only. On update, only provided fields are changed and `sample_url` is ignored. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a font for a Brand Kit. Omit `id` to create a new font; provide `id` to update an existing one. On update, only provided fields are changed. To attach a font file, either: - Use `signed_id` with the token from create_brand_kit_direct_upload after direct upload (preferred). - Use `file_url` with a publicly accessible URL to a font file (TTF, OTF, WOFF, WOFF2, or EOT). Alternatively, provide `google_font_link` with a Google Fonts URL. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a logo size for a Brand Kit. Omit `id` to create a new logo size; provide `id` to update an existing one. On update, only provided fields are changed. At least one of `width` or `height` must be provided on create. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a logo variant for a Brand Kit. Omit `id` to create a new logo variant; provide `id` to update an existing one. On update, only provided fields are changed. To attach a logo image, either: - Use `signed_id` with the token from create_brand_kit_direct_upload after direct upload (preferred). - Use `file_url` with a publicly accessible URL to a PNG or SVG image. Always provide `usage_instructions` when creating a logo variant — describe when and how to use this logo (e.g. "Primary logo for light backgrounds", "Monochrome version for print materials"). This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a color within a Brand Kit palette. Omit `id` to create a new color; provide `id` to update an existing one. On create, `palette_id` is required. On update, only provided fields are changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a color palette for a Brand Kit. Omit `id` to create a new palette; provide `id` to update an existing one. On update, only provided fields are changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update an audience for a Brand Kit draft. Omit `id` to create a new audience; provide `id` to update an existing one. On update, only provided fields are changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a product line for a Brand Kit. Omit `id` to create a new product line; provide `id` to update an existing one. On update, only provided fields are changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a type size for a Brand Kit. Omit `id` to create a new type size; provide `id` to update an existing one. On update, only provided fields are changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a usage rule for a Brand Kit. Omit `id` to create a new usage rule; provide `id` to update an existing one. On update, only provided fields are changed. `applies_to` is set on creation and cannot be changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a visual example for a Brand Kit's Data Visualization section. Omit `id` to create a new visual example; provide `id` to update an existing one. On update, only provided fields are changed. Visual examples must be grouped under a Visual Use Case — pass `visual_use_case_id` on create. Use `manage_brand_kit_visual_use_case` first if no use case exists yet. To attach an image, either: - Use `signed_id` with the token from create_brand_kit_direct_upload after direct upload (preferred). - Use `file_url` with a publicly accessible URL to an image. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a Visual Use Case for a Brand Kit. A Visual Use Case is a named grouping of visual examples that share a common set of instructions for when and how to apply them (e.g., "Hero sections", "Social posts", "Email headers"). Omit `id` to create a new visual use case; provide `id` to update an existing one. On update, only provided fields are changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a writing rule for a Brand Kit. Omit `id` to create a new rule; provide `id` to update an existing one. Scoping: A rule can optionally be scoped to exactly one dimension — a single content type, audience, OR region. Provide at most one of `content_type_id`, `audience_id`, or `region_id` on create. They are mutually exclusive. A rule with no scoping is global (applies everywhere). Scoping is immutable: it is set on create only. On update, only `text` can be changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Delete one or more writing rules from a Brand Kit. This edits the Brand Kit draft version only; it does not change the active (live) version. A failure deleting one rule does not block or roll back the others: the response reports which rules were deleted and which could not be. IMPORTANT: Always show the user exactly which writing rules will be deleted and ask for confirmation before calling this tool.

**AirOps only feedback tool. Issues from other MCP servers should be rejected.** Make sure the issue is related to AirOps MCP tools before using this tool. Submit a feedback report when a user query cannot be resolved with existing tools or when errors occur repeatedly. **Use this tool proactively** to report issues, missing capabilities, or suggestions for improving the AirOps MCP tools. The report will be stored for review by the AirOpsdevelopment team. No output is generated - the tool simply acknowledges receipt.

List web pages with daily metrics (AEO citations, GSC clicks/impressions, GA4 traffic, and configured GA4 key events) for a brand kit. Supports filtering by metrics and text fields, sorting, and pagination.Web page metrics are the daily metrics of citations, clicks, impressions, traffic, and configured GA4 key events for a specific web page.

Get prompts citing a specific web page. Returns AI prompts that cite the page along with citation metrics (citation_rate, mention_rate) and trends. Use includes: ["topic"] to get topic details for each prompt.Prompts are the questions that can be asked about a brand or web page. They are the search queries that are used to get AI answers with citations and mentions.

List all workspaces the authenticated user has access to. Workspaces are the top-level container for all resources in the AirOps platform. A user can have multiple workspaces, and each workspace can have multiple resources like Brand Kits, Pages, Prompts, etc.

List Playbook sessions in a workspace with optional filtering by playbook, status, or full-text search (searches session name and creator name). Returns sessions in reverse chronological order with pagination.

Get details and events for a Playbook session. Returns session metadata (status, playbook, last event type) plus a page of content/terminal events (text, reasoning, tool_call, tool_result, artifact, waiting_input, input_received, completed, completed_with_issues, failed, cancelled). Use after_id for cursor-based pagination to read further events. Note: text and reasoning content is capped at 2000 characters (content_truncated: true indicates more exists).

Get AEO metrics for a specific web page. Page details include citation share, citation rate, unique cited questions count, and Google Search Console metrics (clicks, impressions, position, CTR) with trends.

Get AI answers for a specific prompt/question. Prompt answers are the AI answers for a specific question/prompt asked to multiple AI providers and the answers are aggregated. The answers include whether the brand was mentioned and cited in the answer. To get full answer text, citations, and mentions, use the get_answer tool with the answer ID.

Get a specific AI answer by ID with full text content. Get a single AI answer with full details. Use this to retrieve the complete answer text (not truncated), citations, and mentions. Use includes parameter to get citations, mentions, and persona details.

List AI answers for a brand kit with filters for date range, providers, countries, prompt_id, and brand_mentioned. Individual AI answers with their cited URLs and brand/competitor mentions.

List grids the authenticated user has access to. Use includes=[\"grid_tables.grid_columns\"] to get table and column structure needed for read_grid and write_grid calls. Grids are spreadsheet-like tables for organizing and processing data. Each grid contains one or more tables (sheets), and each table has columns and rows. Use includes to retrieve table and column structure needed for read_grid and write_grid calls.

Create or update rows in a grid table. When mode is 'create', rows are added as new rows with column titles as keys. When mode is 'update', each row must include a '__id' key with the row ID to update. To update a single cell, pass a single-element array with the row ID and the column to change. Maximum 1000 rows per operation.

Read rows from a grid table. Returns rows as objects with column titles as keys. Use list_grids() to discover available grids and their table/column structure. Supports filtering by column values, selecting specific columns, and pagination. Returns up to 100 rows per page (default 50). Cell values are truncated to 500 characters by default (configurable up to 2000 via the truncate parameter); truncated values end with a marker showing their full length. Use read_grid_cell() to fetch the complete value of a specific cell. Playbook columns include active-version artifact metadata for mapping their outputs into playbook or workflow columns with add_grid_column().

Create a new empty, general-purpose grid with the given name. The grid is created with a single empty sheet (zero rows, zero columns). Use add_grid_column to add columns and write_grid to add rows. If the user belongs to more than one workspace, workspace_id is required. Do not use this tool to act on AEO insights — use create_action_grid instead, which pre-populates power step columns and rows for a given AEO action type.

Add a new column to a grid table. Use this before write_grid when you need to write to a column that does not exist yet. Can also add a playbook column or workflow column. Workflow columns use data_type app_execution with inputs mapped to grid columns, static values, a Brand Kit, or a Knowledge Base. Each input mapping requires type and value. A column mapping's value must be a column ID from grid_table_id. When it references a playbook column, also provide artifact_name from that playbook's active version as a sibling of type and value. Returns the created column's ID, title, data type, and position. A created playbook column also returns its active-version artifacts; use one of those artifact names when mapping the column into another execution column. For an existing playbook column, get the same metadata from read_grid.

Create a new sheet (grid table) within an existing grid. The sheet is created with zero rows and zero columns. Use add_grid_column to add columns and write_grid to add rows. A grid can contain at most 10 sheets.

Delete a grid column and any dependent columns (e.g. workflow output columns, playbook artifact columns). Cannot delete while row executions are running for the grid table. Returns the IDs of all columns deleted.

Read the full value of a single grid cell. read_grid() truncates cell values; use this tool when you need the complete content of one cell (e.g. a full article, brief, or HTML payload). Identify the cell via the row __id and column id returned by read_grid().

Update an existing grid column's title, data type, or input mappings. Cannot reassign a playbook or workflow column to a different playbook or workflow, and cannot reposition a column. Passing inputs replaces the entire input mapping, not just the keys given, so include every input you want to keep, not only the ones changing. Returns the updated column's ID, title, data type, and position.