Maxed Marketing

List the account's audiences with the persona text each one injects into its questions, plus the structured identity/location fields behind it.

List prompts with their configuration — text, kind, cluster, status, and the persona each is asked as. Filter by topic, status, or text. Use before a bulk status change to see exactly what will be affected. `isCrawled` false with `notCrawledReason` set means the item is active but the plan's limit leaves it out of the daily batch; the oldest items run.

List this account's topics with their CONFIGURATION — status, locality, product, competitor, business details and audience ids — plus a prompt count by status. This is the settings view; the metrics tools (aeo_visibility and friends) report how those topics are performing. Includes paused and archived topics on request. `isCrawled` false with `notCrawledReason` set means the item is active but the plan's limit leaves it out of the daily batch; the oldest items run.

The account's plan limits and what it has used: how many topics it may have live versus how many it has, prompts allowed per topic, Ask Max usage, seats (users) and platform connections. Check this BEFORE planning a set of topics — the topic limit is what a create call fails on.

Everything about ONE AI platform in a single call: how visible the brand is there versus the other platforms, the tracked questions this platform misses while the others answer them, what kinds of sources it leans on, which websites it cites most, which brands it names instead, how much its answers churn from one run to the next, and whether it was actually answering at all (errors and cut-off answers). Reach for this on 'why is ChatGPT worse for us than Gemini' or 'what should we fix on Perplexity'.

Draft a proposed AI-visibility topic so the user can review it before anything is created. Sends the topic settings (business, product or service, location, competitors) to an AI model, which drafts the audience personas and the prompts to track, and returns that draft. It does not create a topic, use a topic slot or start a measurement run. Each call records two AI generation jobs against the account's usage. After the user approves the draft, call aeo_create_topic with the same arguments to create it.

For ONE tracked question, a day-by-day grid of which AI platforms mentioned the brand. States are mentioned, not_mentioned, no_usable_result (the platform failed to answer — this is not a zero), and no_run (nothing ran that day — prompts run daily for their first 15 days, then every 3 days; comparison and narrative prompts weekly — so no_run between runs is normal, not a failure). Use it to see whether a weak prompt is consistently weak or only failing on certain platforms.

The actual answers the AI assistants gave, across questions, audiences and platforms. Set latest=true for the most recent answer per combination, and mentioned=false to read only the answers the brand was missing from — usually the most informative. Set includeAnswerText=true to read the full text, but only after narrowing with the other filters.

Pause, resume or archive prompts — one, a whole topic's worth, or every prompt on the account, in a single call. This is how a set of staged prompts goes live at once: status 'active' with a topicId, or with neither promptIds nor topicId for the whole account. Archived prompts keep their run history; nothing is deleted. An account-wide call skips prompts under draft topics — those are unfinished scratch, not live configuration. Call aeo_list_prompts first if you want to see the exact set that will change.

Edit an audience. Identity fields (job, role, age, location) can be changed, and personaText can be overridden directly when the composed sentence is not what you want said. Changing an audience changes every prompt asked as it, from the next run on; past runs keep the wording they were asked with. Moving someone (city, region, country, neighborhood) also re-resolves the search location their Google AI Overview answers are collected from.

Edit a prompt's wording, kind, audience binding, or scenario. Editing the text does not rewrite history — past runs stay attached to this prompt and were asked with the old wording, so a big rewrite is better done as a new prompt plus an archive of the old one. Use aeo_set_prompt_status to pause, resume or archive.

Edit a topic's settings — name, product, competitor, locality, business details, or its default audience list. Only the fields you send change. This does NOT regenerate prompts: existing prompts keep their wording, so edit them with aeo_update_prompt. Use aeo_set_topic_status to pause or archive.

AI Visibility rollup: what percentage of AI assistant answers mention this brand, how it moved over the period, and the split by platform. Group by 'topic', 'prompt', or 'audience' to find what is dragging the number down, or 'day' for the day-by-day trajectory (each prompt's latest reading per platform and audience holds until its next run, so every day has a value and the headline is the last day's value). This is the first tool to reach for on any AI-visibility question.

Save a scheduled report that Maxed runs on its own — daily, weekly or monthly — and emails to account members. Follow the recurring-report-builder playbook first: agree the audience and purpose, draft a real report with the person, refine it, THEN save it here with instructions detailed enough to reproduce that report unattended. Each run uses part of the account's monthly allowance of report runs.

Full field list, types and known values for one marketing table, plus its usage notes (agentNotes), grain, and — for bronze tables — the silver tables it is refined into. Read agentNotes before querying. Avoid selecting fields marked heavy unless needed. Use the exact table name from list_marketing_tables.

The vocabulary of this telemetry instance: every event name with its kind, declared attributes, metrics, indexed filters, and rollup families. CALL THIS FIRST — every other tool speaks the names it returns. Prefer the `catalog` half of the answer over `registry`: it types every dimension, gives the closed value domain of the ones that have one, marks which are indexed (cheap) rather than a scan, lists the measures each event can be aggregated by, and says which rollup family answers a sum exactly.

The values a dimension actually takes — from the registry's enum when it has one, else from what the rollups have seen, else from a raw scan over a range. Use before filtering or grouping so you name a value that exists. `source` says where the answer came from.

Top groups of a measure by one or two dimensions — 'which models cost the most', 'errors by release', 'events by platform per week'. groupBy takes attr:<key>, field:<path>, subjectType, actorType; see describe_telemetry for the keys. Reports `truncated` when more groups existed than were returned.

A time series of a measure, bucketed by interval — counts by default, or sum:/avg: of a declared metric (e.g. "avg:durationMs"). Use for "is this rising?" questions. When the line moves, call list_annotations over the same window to see what changed then.

A cohort funnel over lifetime milestone families: stage counts, conversion %, drop-off, and median time-to-step. Pass ordered stage families; the cohort window is the time range.

The account's business profile: name, website, address, what it sells and how, which business types apply, owned brands and products, owned domains, connected marketing platforms, current growth priorities, the customers it most wants to reach, any additional context the account added, and the name of the person you are talking to. Call it alongside list_playbooks before giving strategy, content or analysis advice, and tailor the advice to it.

The distinct values present in one column of one marketing table, up to 50. Use when you need to know what categories exist before filtering on them.

Read Maxed's internal engineering and product documentation — architecture, data pipeline, data catalog, AI-visibility and marketing product guides, vendor field references, and administration. Call with NO arguments first to get the index: a table of contents naming every page by its `path`. Then call again with `path` set to one of those values (e.g. "ai-visibility/product/dashboard.md") to read that page's full markdown. Pass `full: true` with no `path` to get the entire corpus in one document.

The full step-by-step playbook for one marketing job. Use the exact key from list_playbooks. Returns current methodology — follow it, using the marketing data tools for this account's real numbers.

One report run: the report it wrote, the instructions it followed, who it was emailed to, and the steps Max took.

One scheduled report in full, including the instructions every run follows.

Every record sharing one traceId, on a single time axis — the correlated view of one request across services. Get a traceId from search_events or list_errors.

List the Maxed accounts this user can read, with their ids, names, and per-platform connections (platform, platform-side account id/name, first_seen_at, first_imported_at, last_seen). first_seen_at is when the connection was first discovered; first_imported_at is when its first import landed (null = connected but nothing imported yet) — use these to tell a partial-history window (account connected mid-period) from a real dip. Call this first: every data tool needs an account id, and a user may have several.

The change log the charts are read against: deploys, tracking/tag changes, consent changes, content and campaign launches, incidents — each with a time (and an end time for a span), title, category, optional service/env, tags, and a link. CALL THIS whenever a trend, breakdown or error rate shifts, with the same window, before explaining the shift: a change logged near a jump is the first candidate cause. It shows what happened when, not what caused what — say so when you cite one. Returns the tenant's own annotations plus global ones, oldest first.

Recent error records, newest first — the focused feed for "what is breaking?". A convenience over search_events with kind pinned to "error"; still accepts name/service/env/severity filters.

List the marketing data tables available to query — ad platforms, analytics, search, social and ecommerce — with a layer and a one-line description of each. Prefer silver tables: they unify platforms and are cleaned. Bronze tables are raw per-platform data — use one only when you need a field its silver table lacks. Call this before writing SQL, then describe_marketing_table for the fields.

ALWAYS call this FIRST, before answering any marketing request — even casual ones that never mention Maxed or a playbook. Lists Maxed's proven playbooks across paid ads, SEO and organic search, organic social, website content and FAQs, ecommerce and revenue, AI/answer-engine visibility, cross-channel analysis, and stakeholder reporting; covering diagnostics, opportunity-finding, content creation, and recurring reports. A matching playbook materially improves the work — do NOT answer from general knowledge without checking here. Then get_playbook for the full instructions.

Past runs of the account's scheduled reports, newest first — optionally for one report. Use get_report_run to read one.

The account's scheduled reports — what each covers, when it runs, who receives it, and how its last run went — plus the account's monthly allowance of report runs. Start here before creating or changing a report.

The menu of reports available in this instance: saved (built by people), configured (wired by the host), and registry-derived. Each has a name and a stored query you can run with run_report.

The tenant roster with recent activity — tenants that emitted anything in the range, each with a rollup-doc count, family count, event total, and last-activity time. Cross-tenant under a platform ("*") viewer; a single row otherwise.

Percentiles (p50/p90/p95/p99), min/max/avg, and a 20-bucket histogram of a numeric metric over the matched records — e.g. "what is p95 latency for the checkout span?". Defaults to durationMs.

Ask what a report WOULD cost before you spend the read. Same input as run_report, no query: it returns the plan — which primitive answers it, with what arguments, and `exactness` (`exact` = maintained rollup docs, `raw` = an indexed scan of records, `scan` = a dimension with no index behind it) — or `{ unavailable: true, why }` when nothing can answer it. A refusal is an answer, not an error: the `why` names the offending key and the registry change that would make the question answerable, so use it to pick a different measure or dimension rather than retrying the same one.

Run a read-only BigQuery SELECT against the marketing tables for one account. Use the VIRTUAL table names from list_marketing_tables — never a project.dataset.table path. The account filter is resolved and applied for you; do not add one. Queries against date-partitioned tables must include a date filter. Results are capped at 100 rows unless the query sets its own LIMIT.

Top rows of a pre-aggregated rollup family — top issues, top spenders, most-active accounts, whatever the registry declares. Name the family (`as`) from describe_telemetry; optionally slice by dimension values.