# Get a weekly AI visibility digest that can say nothing happened

> For the complete documentation index, see [llms.txt](https://attensira.com/llms.txt).
> Every page on this site is also served as Markdown: append `.md` to any URL, or send `Accept: text/markdown`.

> Set up a weekly AI visibility digest from your assistant over the Attensira MCP server: check what exists, write an instruction that can say nothing, test it.

- Canonical page: https://attensira.com/mcp/use-cases/schedule-a-weekly-visibility-digest
- Family: mcp-use-cases
- Last updated: 2026-10-04
- Author: Karl-Gustav Kallasmaa (https://x.com/kallasmaa)
- Claims as data: https://attensira.com/claims.json?slug=schedule-a-weekly-visibility-digest

**In short:** Ask your assistant to call list_automations, then create_automation on the Attensira MCP server with a weekly trigger, a time and an instruction that ignores changes not marked real. Creating it is free; each run spends credits. Run it once with run_automation and an idempotency key, then read get_automation before trusting it unattended.

## What it showed on attensira.com (read 2026-10-04)

Asked in Claude: "What automations do we already have before I add a weekly digest?"

Call: `list_automations`

Two, and neither is a weekly digest. The crew's daily plan already runs every morning.

| Row | Value | Note |
| --- | --- | --- |
| Daily win plan | daily, 06:00 | active · last run 4 October, 06:01 |
| Event responder | on 5 event types | a lost prompt or citation, a rival or page change, a new deciding source |

_The first step of the chain, because two automations doing one job bill twice._

## Which call answers it?

```json
{ "tool": "create_automation", "arguments": { "name": "Monday visibility digest", "instruction": "Summarise the last 7 days: workspace mention and citation rates with deltas, the five worst prompts, per-platform split, and any competitor whose rate moved with real:true. Ignore deltas where real is false.", "trigger": "weekly", "timezone": "Europe/London", "run_at_minute": 540 } }
```

## What is the chain behind it?

1. **Call list_automations before you create anything** list_automations takes no parameters and returns every automation in the workspace with its name, instruction, trigger, allowed tools, status, timezone, run_at_minute and last_run_at. Two automations doing the same job bill twice, and this is the one call that stops that happening.
2. **Create the automation and write the instruction precisely** create_automation needs a name, an instruction in plain language and a trigger of manual, once, daily or weekly. Creating costs nothing. Name the exact areas and windows you want in the instruction, and say explicitly that deltas where real is false should be ignored, or the digest will report noise as change.
3. **Pin when it fires, and narrow what it may call** run_at_minute is minutes past local midnight from 0 to 1439, so 540 is 09:00, and it is read in the IANA timezone you pass rather than UTC. The optional tools array is an allow-list of tool names the automation may use; omit it to allow everything the plan includes.
4. **Trigger it once with an idempotency_key, then read the history** run_automation fires it immediately outside its trigger, spends credits and returns a session handle to poll with get_session rather than a finished result. Pass an idempotency_key on every call so a retry does not bill twice. get_automation then returns the full definition with the most recent run inline as latest_run.

## How do I read what comes back?

| What you see | What it means |
| --- | --- |
| The digest reports every delta as a change | The instruction did not exclude real:false. A delta with real:false failed a two-proportion z-test at 95%, so there is no change to report in either direction. |
| A week with no findings | Normal, and the correct output. Most weeks contain no statistically real movement. |
| Numbers that differ from the dashboard | Check the window. Seven days against a 30-day default is a different slice, not a bug. |
| A run missing from latest_run and the history | The scheduled run did not execute. Re-run it manually with a fresh idempotency key rather than assuming the week was quiet. |

## What can't this tell you?

- A weekly cadence over a daily sampling floor means each report rests on at most seven readings per prompt per platform, or three times that on Growth and Business where sampling depth is three. That is thin for week-over-week comparison, and a digest that dutifully reports movement every week is reporting noise.
- The digest reports what was measured, not what exists. A platform your plan does not track is never queried, so it comes back null rather than zero, and a report that renders null as 0% invents a failure that did not happen.
- Creating an automation is free but every execution it triggers spends credits, on the schedule as well as on a manual run. The cost of a weekly digest is a recurring cost, and nothing in the create call tells you what it will be.

### What did it show on our own workspace?

Our own workspace already ran a daily plan and an event responder, but no weekly digest. That is why the chain starts with `list_automations`: the job you are about to create may already be done, or done differently, by something that bills on every run. A workspace that has been running for a year usually has one nobody remembers creating.

### Why should the instruction be allowed to say nothing?

A delta comes back as `{value, real}`, and `real: false` means the movement did not clear a two-proportion z-test at 95%: there is no change you can prove, in either direction. An instruction that does not exclude those finds something every week, which is exactly what a digest should not do. A week with no findings is the correct output most weeks; a digest that never produces one is broken.

### Why narrow the tools a scheduled job may call?

The optional `tools` array is an allow-list. Omit it and the automation may use everything your plan includes. A digest has no business calling `remove_prompt`, and a scheduled job runs when nobody is watching. Name the read tools it needs and nothing else.

When the digest flags something, the manual chain that finds the cause is [where you lost ground this week](/mcp/use-cases/find-where-you-lost-ground-this-week). If it names a rival, read [whether they are actually gaining](/mcp/use-cases/check-whether-a-competitor-is-gaining) before reacting.

## FAQ

### Does creating an automation cost credits?

No. create_automation is free and needs write access: any signed-in connection, or a read-and-write key. Every run it triggers spends credits, whether that run came from the schedule or from a manual run_automation call.

### What is the idempotency_key for?

It maps to the Idempotency-Key header upstream, so a retried or duplicated run_automation call does not produce a second billed run. Pass one on every call.

### How do I stop the digest reporting movement that is not real?

Say so in the instruction. A delta comes back as value and real, and real:false means the change did not clear a two-proportion z-test at 95%. An instruction that does not exclude those will summarise noise every week.

### When exactly does a weekly automation fire?

At run_at_minute minutes past local midnight in the timezone you passed — 540 is 09:00 — with UTC as the default when you pass no timezone. run_at_minute is only meaningful for daily and weekly triggers; manual and once never fire on a clock.

### How do I check it actually ran without waiting a week?

Call run_automation once with a fresh idempotency key to trigger it now, then get_automation, which returns the definition with its most recent run inline as latest_run. That is one call rather than two.

## Sources

Each entry below is one claim on this page. `retrieved` is the date the exporter or a human last saw the source say this, and nothing more: it is not a publication date and not a promise of re-verification. `cite` is the anchor on the canonical page where this claim is rendered.

### create-free-runs-spend

Attensira's MCP tool reference states that creating an automation costs nothing and every run it triggers spends credits.

- source: https://docs.attensira.com/mcp/tools (docs.attensira.com)
- retrieved: 2026-10-04
- cite: https://attensira.com/mcp/use-cases/schedule-a-weekly-visibility-digest#claim-create-free-runs-spend

> Creating costs nothing; each run it triggers does.
### idempotency-key

Attensira's MCP tool reference states that run_automation's idempotency_key is sent as the Idempotency-Key header, so a retried call does not bill a second run.

- source: https://docs.attensira.com/mcp/tools (docs.attensira.com)
- retrieved: 2026-10-04
- cite: https://attensira.com/mcp/use-cases/schedule-a-weekly-visibility-digest#claim-idempotency-key

> It maps to the `Idempotency-Key` header upstream, so a retried or duplicated call does not produce a second billed run.