أدوات عبر المنصات
في هذه الصفحة 34 أداة. هذه الصفحة مولَّدة آليًا من قائمة الأدوات في الخادم نفسه، الإصدار 0.1.0، ولا تُحرَّر باليد. أوصاف الأدوات مكتوبة للمساعد الذكي، وهي بالإنجليزية ولم تُترجم، فكل ما تحت هذه الفقرة بالإنجليزية كما يقرؤه المساعد الذكي. لا تحتاج إلى معرفة اسم أي أداة لتطلب عملًا: هذه الصفحة مرجع لمن يريد أن يعرف ما تأخذه كل أداة بالضبط. صفحة كل الأدوات تسرد الصفحات كلها.
queue_list
Kind: read. It is marked as changing nothing.
List your queued posts: the ones this server is holding to publish at a time (Instagram and LinkedIn, which cannot schedule a post themselves), soonest first.
status is pending (waiting for its time), running (being published now), failed (it was tried and refused - error says why), missed (the server was not running at its time and came back too late to publish it unasked) or done (published in the last week). A failed or missed post stays until someone publishes, moves or cancels it. A scheduled Facebook post is not here: Facebook holds it, and meta_list_posts shows it.
It takes no arguments.
queue_reschedule
Kind: write. It only previews the change unless dry_run is false. Not offered while the server is in read-only mode.
Move a queued post to another time. A failed or missed one goes back to waiting. To change its text or media, cancel it and queue it again.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
queue_id | text | yes | From queue_list, or the queue_id returned when the post was queued. | |
schedule_at | text | yes | The new time, ISO 8601 or a Unix timestamp, up to 90 days ahead. | |
dry_run | true or false | no | true | true = show what would change (default). false = move it, after the user confirms. |
queue_publish_now
Kind: write. It only previews the change unless dry_run is false. Not offered while the server is in read-only mode.
Publish a queued post now instead of waiting for its time - also how a failed or missed one is tried again. It goes live for everyone, and what people saw cannot be taken back.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
queue_id | text | yes | From queue_list. | |
dry_run | true or false | no | true | true = preflight only (default). false = publish it, after the user confirms. |
queue_cancel
Kind: write. It only previews the change unless dry_run is false. Not offered while the server is in read-only mode.
Cancel a queued post that has not been published. Nothing was ever sent to the platform, so nothing is removed there and nobody loses anything.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
queue_id | text | yes | From queue_list. | |
dry_run | true or false | no | true | true = show what would be cancelled (default). false = cancel it, after the user confirms. |
notifications_list
Kind: read. It is marked as changing nothing.
List what this server has to tell you, newest first: a queued post that failed, was missed or was interrupted, a Meta or LinkedIn connection that is about to end, an account this server was watching for you (history_list) and can no longer read, a lead feed (leads_feed_list) that cannot deliver its leads.
Each has a title, a body saying what happened and what can be done, and often a link to the page of the management site where it is dealt with. Tell the user about the unread ones, then mark them read with notifications_mark_read so they are not reported twice. delivered says whether it also went out by webhook or email; delivery_error is why a channel did not take it, which only an administrator can fix.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
unread_only | true or false | no | true | true = only what has not been marked read (default). false = read ones too. |
limit | whole number | no | 25 | How many to return, 1-100. |
notifications_mark_read
Kind: write.
Mark notifications as read, once the user has been told of them. Nothing is deleted and nothing on any platform changes: they only stop counting as unread.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
ids | list of whole number | yes | The id of each notification to mark, from notifications_list. |
history_list
Kind: read. It is marked as changing nothing.
List what this server reads by itself for you: the accounts you asked it to watch, since when, and when each was last read.
enabled is the administrator's switch: while it is false nothing is read for anyone. last_read_at is the last pass that read the account; when last_error is set the passes since have failed and it says why, and stopped means the server gave up until that is put right (you were sent a notification). For an account kept a day at a time, held gives the first and last day kept and how many days between them are missing. kinds lists what can be watched, what is kept of it and what it costs in calls.
It takes no arguments.
history_watch
Kind: write. It only previews the change unless dry_run is false.
Have this server keep reading an account by itself, so that figures the platform drops are kept. Four kinds:
- platform "meta", kind "instagram_stories": Meta drops a story's figures 24 hours after it was posted; a watched account's stories are read before then and kept for meta_story_report. From the moment it is watched, never backwards.
- platform "meta", kind "facebook_page" (a Page id), or kind "instagram_account" (an Instagram account id): the account's own daily figures, and weekly who its followers are, kept a day at a time for history_report.
- platform "linkedin", kind "linkedin_page" (an organization id): the Page's followers, views and post totals a day, and weekly its followers by function, seniority and the rest. LinkedIn's terms allow these one year, so each day is deleted a year on.
A daily kind first reads back what the platform still has (90 days of a Page, 30 of an Instagram account, 12 months of a LinkedIn Page), then keeps each day once it has ended. Only while this server is running: a day it was off for more than a week is a gap. Watching sends nothing to the platform and changes nothing there; it starts read calls on your own connection, which is why it is asked for per account and confirmed. Off until an administrator switches History on.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
platform | text | yes | "meta" or "linkedin". | |
kind | text | yes | One of the four above. | |
account_id | text | yes | The account's id, from meta_list_accounts or linkedin_list_accounts. | |
dry_run | true or false | no | true | true = show what would be watched and what it costs in calls (default); it sends nothing anywhere. false = start watching, after the user confirms. |
history_report
Kind: read. It is marked as changing nothing.
What this server kept of an account you had it watch, a day at a time: the figures of a past range, by day, week or month, with the period before beside them. It asks no platform anything, so it also answers for days the platform no longer has - but only for days the account was watched and the server was running.
gaps lists the days nothing is held for. They are left out of every series and total, never counted as zero: say so when you quote a total over a range that has them. A metric that is a running level (followers) gives latest, not a total. One that counts people (reach, unique views) or is a rate is given per day only and is never added up.
Metrics kept: for a Facebook Page the meta_page_insights defaults (page_follows, page_daily_follows_unique, page_media_view ...); for an Instagram account followers_count, media_count and the meta_instagram_account_insights metrics; for a LinkedIn Page followers, followers_gained (and _organic, _paid), page_views, unique_page_views, impressions, unique_impressions, clicks, reactions, comments, shares, engagement.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
platform | text | yes | "meta" (a Page or an Instagram account) or "linkedin". | |
account_id | text | yes | The account's id, as it was watched (history_list shows them). | |
since | text | yes | First day of the range: a date (2026-09-01, read as UTC). | |
until | text | yes | The day the range ends, not included: for all of September give 2026-10-01. | |
metrics | text | no | none | Comma-separated names. Default: everything held for the account. |
granularity | text | no | "day" | day (the default), week (from Monday) or month. |
compare_to | text | no | none | previous_period (the same number of days just before) or previous_year (not for LinkedIn, whose figures are kept one year at most). Adds previous and change. |
by | text | no | none | Also give the newest breakdown kept on or before the end of the range: country or city (a Page's followers), age, gender, country or city (an Instagram account's), function, seniority, industry, company_size, country, region or association (a LinkedIn Page's). It is of one day, not of the range. |
history_unwatch
Kind: write. It only previews the change unless dry_run is false.
Stop this server reading an account by itself. What it already kept stays until this installation's retention removes it; nothing on the platform changes.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
platform | text | yes | As in history_list. | |
kind | text | yes | As in history_list. | |
account_id | text | yes | As in history_list. | |
dry_run | true or false | no | true | true = show what would stop (default). false = stop, after the user confirms. |
utm_build
Kind: read. It is marked as changing nothing.
Tag a link with its utm parameters, so that the website's analytics can say which post or ad a visit came from. Use the link it returns wherever a post or an ad carries an address of the user's own website. Nothing is sent anywhere and nothing is stored.
The source and medium are fixed lists. The campaign, content and term are written by one rule (lower case, hyphens between words, letters of any language kept), so the same campaign is spelled alike everywhere: use the same campaign for every link of one campaign. utm parameters already on the address are replaced; its other parameters and its #fragment are kept.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
url | text | yes | The whole address, starting with https://. | |
source | text | yes | Where the click comes from: facebook, instagram, linkedin or google. | |
medium | text | yes | social (an organic post), paid_social (an ad on Facebook, Instagram or LinkedIn), cpc (a Google Ads click) or email. | |
campaign | text | yes | The campaign's name, e.g. "Autumn offer 2026". | |
content | text | no | none | What tells two links of one campaign apart, e.g. "video-a" or "carousel". |
term | text | no | none | The keyword, for a search ad. |
leads_export
Kind: read. It is marked as changing nothing.
Export the new leads of the lead forms you can read on Meta, Google Ads and LinkedIn, in one shape, to hand to a CRM or a sheet: {platform, lead_id, created_at, form_id, form_name, campaign_id, campaign_name, ad_id, ad_name, fields: {email, phone, full_name, first_name, last_name, company, job_title, city, country ...}, custom: [{question, answer}], click_id (Google's gclid), test}.
A lead is a person's contact details. Call this only when the user asks for leads to be exported, hand them to the system the user named and nowhere else, and never repeat them elsewhere. Each platform's own rules apply unchanged: an administrator's switch for reading leads there, your write access, and the permission on your connection. Nothing of a lead is stored on this server; its activity log keeps where leads were read from and how many.
New means after your own mark. This call moves nothing: it returns a cursor, and leads_mark_exported(cursor) records that those leads reached the user's system. Until you mark, the next export returns the same leads again, so a failed hand-over loses nothing - and the receiver should treat lead_id as the key. When more is true, call again with the cursor to read the rest before marking.
A platform that is switched off, not connected or throttled is listed under skipped with its reason; the others are still read. Tell the user what was skipped and why.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
sources | list of text | no | none | Which to read. A platform ("meta", "google", "linkedin") reads up to 10 of its Pages or accounts; "meta:<page id>", "google:<customer id>" or "linkedin:<ad account id>" reads that one. Left out, all three platforms. |
since | text | no | none | Read from this time instead of from your mark: ISO 8601 with an offset, e.g. 2026-10-01T00:00:00+03:00. For a first export, or to export again. |
cursor | text | no | none | The cursor of the previous call, when its more was true: continues it. |
limit | whole number | no | 100 | Leads in one call (1-500, default 100). |
leads_mark_exported
Kind: write.
Record that the leads of a leads_export call reached the user's own system, so the next export starts after them. Call it only once that system has them. It touches nothing on any platform, only your own marks on this server, and only forward.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
cursor | text | yes | The cursor leads_export returned. |
leads_feed_list
Kind: read. It is marked as changing nothing.
List your lead feeds: the Pages and ad accounts whose new leads this server pushes to the organisation's lead webhook by itself, since when, when each last looked and delivered, and how many leads it has delivered.
enabled is the administrator's switch and webhook_configured whether there is anywhere to push to: while either is false nothing is read or sent for anyone. failing with last_error means the passes since have failed and why (you were sent a notification); the server keeps trying and no lead is skipped while the platform still holds it.
It takes no arguments.
leads_feed_add
Kind: write. It only previews the change unless dry_run is false.
Have this server push the new leads of one Facebook Page, Google Ads account or LinkedIn ad account to the organisation's own lead webhook (its CRM), every few minutes, with nobody asking each time.
A lead is a person's contact details, and a feed sends them on without a person in between: set one up only when the user asks for exactly that, never as a convenience. Where the leads go is the one webhook an administrator set for this installation; this tool cannot name or change it. It needs the administrator's switch for pushing leads, your write access, and everything reading that platform's leads needs (its own switch and the permission on your connection) - all asked again at every look, so a feed stops by itself when one of them is taken away, and tells you.
A feed starts with the leads that arrive from now on; leads_export reads earlier ones. It covers every lead form of the source. Nothing of a lead is stored on this server. Delivery is at least once: the receiver may get a lead twice and keys on each lead's key. dry_run=true (the default) reads how many forms the feed would cover and sends nothing to the webhook; show the user the preview before dry_run=false.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
platform | text | yes | "meta", "google" or "linkedin". | |
source_id | text | yes | A Facebook Page id (meta), a Google Ads customer id (google) or a LinkedIn ad account id (linkedin). | |
dry_run | true or false | no | true | true = preview only (default). false = start pushing. |
leads_feed_remove
Kind: write. It only previews the change unless dry_run is false.
Stop pushing the new leads of one Page or ad account to the lead webhook. Only your own feed, and nothing on any platform changes: the leads stay where they are.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
platform | text | yes | "meta", "google" or "linkedin". | |
source_id | text | yes | The feed's source_id, as leads_feed_list shows it. | |
dry_run | true or false | no | true | true = preview only (default). false = stop. |
content_calendar
Kind: read. It is marked as changing nothing.
Your posts on Facebook, Instagram and LinkedIn that are not live yet, in one list sorted by time - and, when asked, what went live. Each item has platform, account, state, time (UTC), the first line of its text, its id and the tools that act on it.
States: scheduled (a Facebook post Facebook holds and publishes itself), queued (an Instagram or LinkedIn post this server holds and publishes at its time), failed and missed (a queued post that did not go out: it waits for a person, and is listed whatever the range), draft (held with no time; listed last) and published.
This reads this server's own records - the post queue, the Facebook posts it scheduled, your LinkedIn drafts and your own activity log - so it knows only posts made through this server. The one thing it asks a platform is whether each Meta draft is still there, one call a draft; include_drafts=false skips that. A post you deleted through this server is not listed. It changes nothing: to move, publish or cancel an item use the tools it names, each on the user's own word.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
since | text | no | none | Only items from this time: a date (2026-10-01, read as UTC) or an ISO 8601 date-time. Left out: from now (for published items, the last 7 days). |
until | text | no | none | Only items before this time, in the same form. Left out: everything ahead. |
include_published | true or false | no | false | Also list what went live in the range, from the activity log. |
include_drafts | true or false | no | true | List drafts as well (the default). false saves the Meta re-read. |
marketing_overview
Kind: read. It is marked as changing nothing.
One view of a period across every platform you have connected: start a reporting question here, then go into detail with the platform's own tools.
paid: per ad account (Meta Ads, Google Ads, LinkedIn Ads) spend, impressions, clicks, leads and cost per lead, in the account's own currency; Google Ads gives conversions in place of leads. organic: per Facebook Page, Instagram account and LinkedIn Page the followers, followers gained, views or impressions, interactions and posts made. Each has totals. top_posts and top_ads are the five highest by a stated measure.
Read these before reporting the figures:
- Money is never added across currencies: spend is totalled per currency only.
- Reach is not here, and followers are not totalled: they count people, who cannot be added up across platforms, posts or days. Do not add them up either.
- A platform that is switched off, not connected or refuses is listed under skipped with its reason, and is in no total. Say which and why.
- A change against an earlier period, and "top", are this server's arithmetic by the rule stated in the answer - never a platform's verdict. Where there is nothing to compare with the answer says "no earlier figure": do not turn that into a zero.
- Each platform's own switches, permissions and allowed ad accounts apply unchanged.
With no accounts named, the first account of each platform is read and the others are named under accounts_not_included. A full overview of six accounts is about 25 calls to the platforms (11 to Meta, 12 to LinkedIn, 2 to Google Ads: a call or two a figure, never one per post or ad); compare_to adds about 8 and include_top=false saves about 4. A period over 30 days costs Instagram two more calls a further 30 days.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
since | text | yes | First day of the period, YYYY-MM-DD. | |
until | text | yes | Last day of the period, included, YYYY-MM-DD. At most 92 days (a quarter). | |
compare_to | text | no | none | previous_period (the same number of days just before) or previous_year (the same dates a year earlier). Left out, no comparison. |
accounts | list of text | no | none | Which to read: a platform (meta_ads, google_ads, linkedin_ads, facebook, instagram, linkedin) for its first account, or "<platform>:<account id>" for that one, up to 5 a platform. Only the platforms named are read. Left out, all six. |
include_top | true or false | no | true | Also rank the top five posts and ads (the default). |
budget_overview
Kind: read. It is marked as changing nothing.
How a month's ad spend stands against what you planned: per ad account (Meta Ads, Google Ads, LinkedIn Ads) the plan, the spend of the month so far, the daily budgets live now, the spend the month is projected to end at, and a pace word.
Read these before reporting it:
- pace (ahead, behind, on_pace, too_early, no_plan; finished_* for a past month) is this server's arithmetic by the rule in notes, never the platform's verdict. Say it as that, with the two figures it compares.
- A plan is the user's own figure, set with budget_plan_set. It limits nothing: no change is refused or made because of it. The limits that refuse are an administrator's (the Safety limits page; server_status shows them).
- Money is per currency: by_currency totals each currency alone. Never add or convert.
- An account under skipped was not read and is in no total: say which and why.
It changes nothing. To act on what it shows, use the platform's own budget tools on the user's word.
With no accounts named it reads the ad accounts that have a plan for the month; with no plan at all, the first ad account of each platform. Two or three calls an account.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
month | text | no | none | YYYY-MM. Left out, the current month. A month that has not begun lists its plans only. |
accounts | list of text | no | none | Which to read: "meta_ads", "google_ads" or "linkedin_ads" for the first account, or "<platform>:<account id>" for that one, up to 5 a platform. |
budget_plan_set
Kind: write. It only previews the change unless dry_run is false.
Record what the user means to spend on one ad account in a month, so budget_overview and a budget_pace alert rule have something to compare the spend with.
A plan is a note on this server and nothing else: it is sent to no platform, changes no budget, and never refuses anything. Use the user's own figure, in the ad account's own currency - do not invent one from the budgets you see. amount=0 removes the plan.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
platform | text | yes | "meta_ads", "google_ads" or "linkedin_ads". | |
account_id | text | yes | The ad account id (Google Ads: the customer id). | |
amount | number | yes | The month's plan in the account's currency. 0 removes it. | |
month | text | no | "every" | YYYY-MM for that month alone, or "every" (the default) for every month that has no plan of its own. |
dry_run | true or false | no | true | true = preview only (default). false = save. |
alerts_list_rules
Kind: read. It is marked as changing nothing.
List your alert rules with how each last went, the kinds of rule there are, and your budget plans.
state is tripped (you were told, and no check has found it over since), clear, not_checked_yet, cannot_be_checked (last_error says why; you were sent a notification) or off. last_value is the figure the last check worked out and last_note what it saw. A rule only ever sends a notification (notifications_list reads them): it never pauses or changes anything.
It takes no arguments.
alerts_set_rule
Kind: write. It only previews the change unless dry_run is false.
Have this server watch one figure of one account and send a notification when it crosses a line. Offer one when the user says "tell me if" or "warn me when".
A rule only tells: it never pauses an ad, never changes a budget or a status, and has no way to. It tells once per breach, and again only after a check has found the breach over. It is checked on your own connection, so it stops by itself - and says so once - when the connection, the platform's switch or the account's permission is taken away.
Kinds (there are no others, and none judges what comments say):
- cpl_above: cost per lead over window_days is above threshold (account currency).
- spend_no_leads: the account spent over window_days and brought no lead; threshold is an optional amount of spend to let pass.
- ad_rejected: an ad's review turned to rejected. No threshold, no window.
- budget_pace: the month projects to end more than threshold percent (default 10) over the plan set with budget_plan_set.
- follower_drop: followers fell more than threshold percent (default 5) over window_days. Needs the account watched with history_watch.
- comment_spike: more than threshold new comments within a day on the account's recent posts. A count only: read the comments to see what they say.
The first four are for meta_ads, google_ads and linkedin_ads (on Google Ads "lead" means a conversion); the last two for facebook, instagram and linkedin.
Setting a rule that exists changes it and starts it over. At most 25 rules a person. dry_run=true (the default) shows what it would watch and what it costs in calls; show the user before dry_run=false.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
kind | text | yes | One of the six kinds above. | |
platform | text | yes | meta_ads, google_ads, linkedin_ads, facebook, instagram or linkedin. | |
account_id | text | yes | The ad account, Page, Instagram account or LinkedIn organization id. | |
threshold | number | no | none | What the kind compares with (see the kinds). Money is in the account's own currency. |
window_days | whole number | no | none | 1, 3, 7, 14 or 30 whole days ending yesterday, for the kinds that take a window. Left out, the kind's default. |
enabled | true or false | no | true | false keeps the rule but stops checking it. |
dry_run | true or false | no | true | true = preview only (default). false = save the rule. |
alerts_remove_rule
Kind: write. It only previews the change unless dry_run is false.
Remove one of your alert rules. Nothing on any platform changes.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
rule_id | whole number | yes | The rule's id, from alerts_list_rules. | |
dry_run | true or false | no | true | true = preview only (default). false = remove it. |
reports_schedule
Kind: write. It only previews the change unless dry_run is false.
Have this server build marketing_overview by itself every week or month, for the period that just ended compared with the one before, and deliver it to the user.
Read these before offering it:
- A report is tables of figures only. This server has no model: it writes no summary and no advice. When one arrives, the user can ask you to read it (reports_get).
- deliver names where it goes, and there are only three places: "email" is the user's own notification address (they set it on their Notifications page), "webhook" is this installation's notification webhook, "file" keeps it on this server for the Reports page and reports_get. There is no argument for an address: never try to send a report to anyone else, and tell a user who asks for that to forward the mail.
- It is read on the user's own connection each time, behind each platform's own switch, permission and allow-list. A platform that refuses is a skipped section; the rest is still delivered.
- weekly: built on the weekday given at 06:00 UTC for the seven days before it. monthly: built on the first for the month before. There is no other interval.
Setting a name that exists changes that schedule. At most 5 schedules a person. dry_run=true (the default) shows when the first report comes and what it covers; show the user before dry_run=false.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
name | text | yes | What the report is called: the mail's subject and its title here. | |
every | text | yes | "weekly" or "monthly". | |
deliver | list of text | yes | One or more of "email", "webhook", "file". | |
weekday | text | no | none | For weekly: "monday" (the default) to "sunday", the day it is built. |
accounts | list of text | no | none | Which to read, as marketing_overview takes them: "<platform>" for its first account or "<platform>:<account id>". Left out: the first account of each platform. |
enabled | true or false | no | true | false keeps the schedule but builds nothing. |
dry_run | true or false | no | true | true = preview only (default). false = save the schedule. |
reports_list
Kind: read. It is marked as changing nothing.
List your scheduled reports with when each next comes and how its last run went, the reports already built with where each was delivered, and the ways a report can be delivered on this installation.
A report whose file_kept is true can be read with reports_get. status "interrupted" means the server stopped while building it and whether it was sent is not known.
It takes no arguments.
reports_get
Kind: read. It is marked as changing nothing.
Read one of your built reports as rows of figures (the MCP protocol cannot carry the file; the Reports page downloads it as a CSV).
Each row is one figure: section (paid, organic, paid_total, organic_total, skipped, not_included, note), platform, account, currency for money, metric, value, and where there was an earlier period its figure, the change and the change in percent. A change is this server's arithmetic, not a platform's judgement; "no earlier figure" in note means there was nothing to compare with, never a zero. Money is per currency: never add or convert. A skipped row was not read and is in no total. The figures are as they stood when the report was built.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
report_id | whole number | yes | The report's id, from reports_list. |
reports_remove
Kind: write. It only previews the change unless dry_run is false.
Remove one of your scheduled reports. The reports it already built stay until retention removes them. Nothing on any platform changes.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
schedule_id | whole number | yes | The schedule's id, from reports_list. | |
dry_run | true or false | no | true | true = preview only (default). false = remove it. |
reports_run_now
Kind: write.
Build one of your scheduled reports now, for the period that last ended, and deliver it the ways its schedule says - to you, the webhook or a file; never anywhere else.
It reads the platforms on your connection (what one marketing_overview with a comparison costs) and writes to none. The scheduled report still comes on its day. Use it on the user's word, not to check that a schedule works after every change.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
schedule_id | whole number | yes | The schedule's id, from reports_list. |
website_list_properties
Kind: read. It is marked as changing nothing.
List what your Google login can read of the website: Google Analytics 4 properties (with their account) and Search Console sites (with your permission on each). Call it first: the other website_* tools take a property_id or a site_url from here.
Read only. A row with allowed=false is outside this installation's allow-list and the other tools refuse it; a site with readable=false is one the login has not verified. If the connection holds only one of the two permissions, the other list is empty and a note says how to grant it.
It takes no arguments.
website_traffic
Kind: read. It is marked as changing nothing.
What visitors did on the website in a period, from Google Analytics 4: sessions, users, new users, engaged sessions, engagement rate, key events (what GA4 used to call conversions) and the key-event rate per session.
Read only. The split is one of a fixed list; there is no free-form GA4 report. Rates are fractions of 1. GA4's newest day is incomplete. Each report costs the property some of its daily quota, which the answer reports: do not ask for the same report twice.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
property_id | text | yes | The GA4 property, a number from website_list_properties. | |
since | text | yes | First day, YYYY-MM-DD, in the property's own time zone. | |
until | text | yes | Last day, YYYY-MM-DD. | |
by | text | no | "date" | One of date, source_medium, channel, campaign, landing_page, country, device. By date the rows are in date order; otherwise the most sessions first. |
filter_source | text | no | none | Only sessions from this source, exactly (e.g. "facebook", "google"). |
limit | whole number | no | 100 | Most rows to return (1-1000). |
website_campaign_traffic
Kind: read. It is marked as changing nothing.
What the clicks of each campaign did on the website, from Google Analytics 4: the same figures as website_traffic, by session campaign, source and medium - the three values utm_build writes into a link. This is how to check what a post's or an ad's clicks did after they landed.
Read only. A link tagged today shows here from tomorrow. A campaign named "(not set)" or a source "(direct)" is traffic that carried no tag. The platforms' own click counts and GA4's sessions never match exactly: they count different things.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
property_id | text | yes | The GA4 property, a number from website_list_properties. | |
since | text | yes | First day, YYYY-MM-DD. | |
until | text | yes | Last day, YYYY-MM-DD. | |
utm_campaign | text | no | none | Only this campaign, exactly as utm_build gave it (utm_campaign). |
limit | whole number | no | 100 | Most rows to return (1-1000). |
website_search_queries
Kind: read. It is marked as changing nothing.
How the website did in Google Search in a period, from Search Console: clicks, impressions, CTR (a fraction of 1) and average position, by search query, page, country, device or date. Web search results only.
Read only. Dates are in Pacific time, as Search Console counts them, and its newest two or three days are preliminary. Countries are three-letter codes (sau, egy, kwt). Search Console keeps 16 months.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
site_url | text | yes | The site as website_list_properties gives it: https://www.example.com/ or, for a domain property, sc-domain:example.com. | |
since | text | yes | First day, YYYY-MM-DD. | |
until | text | yes | Last day, YYYY-MM-DD. | |
by | text | no | "query" | One of query, page, country, device, date. |
filter_page | text | no | none | Only this page: a whole address (matched exactly) or a part of one, such as /pricing (pages that contain it). |
filter_query | text | no | none | Only queries that contain this text. |
limit | whole number | no | 100 | Most rows to return (1-1000), the most clicked first. |
server_status
Kind: read. It is marked as changing nothing.
Show who you are acting as, whether your account may write, which platforms your account has connected, and the active server-side safety limits.
It takes no arguments.
get_audit_log
Kind: read. It is marked as changing nothing.
List recent write actions performed through this server, newest first. You see your own actions; administrators see everyone's.
| Argument | Type | Required | Default | Description |
|---|---|---|---|---|
limit | whole number | no | 50 | Maximum entries to return (1-500). |
platform | text | no | none | Filter by platform, e.g. "google_ads". |
include_dry_runs | true or false | no | false | Also include validate-only (dry run) attempts. |