Audits, tasks and credits

The MCP tools for running a Website Audit, working the Tasks board, improving a page section by section, reading the change timeline and checking credits.

These tools close the loop between finding something and doing something about it. start_site_audit dispatches a crawl, get_site_audit_issues reads what it found, the task tools turn findings into work, the page-improvement tools rewrite one page with a person deciding every section, get_site_timeline explains what changed and when, and the two credit tools tell you what any of it costs before you commit.

Tool	Scope	What it does
`apply_page_optimisation`	publish	Writes the sections of a page improvement the user accepted to the live website, and refuses any section that was edited on the site after the suggestion was made rather than overwriting it. Free, and revert_page_optimisation undoes it exactly.
`apply_task_fix`	publish	Applies a task's recommended fix to a connected WordPress site, currently the SEO title and meta description. Dry run first: it returns the exact before and after, plus a run id you pass back to apply it.
`create_task`	write	Creates a task on a Website's Tasks board. Additive only, and it deduplicates: if an open task already tracks the same source, that task is returned rather than a copy.
`decide_page_optimisation`	write	Records which sections of a page improvement the user accepted and which they rejected, once they have seen each before and after. That decision is exactly what apply_page_optimisation writes.
`get_credit_balance`	read	Credits available now, credits held by work in flight, the plan allowance, any trial, and grant expiry dates. Free to call, and the right call before proposing anything that spends.
`get_credit_usage`	read	Where credits went over a period, grouped by action or by Website. Work that failed and was refunded is excluded, so it never reads as spend.
`get_page_optimisation`	read	One page improvement in full: every section, the proposed rewrite where there is one, the checks it must pass and, 28 days after it is applied, what moved.
`get_site_audit_issues`	read	The issues from the most recent completed Website Audit, with severity, category, affected page counts and fix guidance, plus the overall score and crawl statistics.
`get_site_audit_status`	read	Polls an audit job started by start_site_audit. Once it reports complete, the findings are read with get_site_audit_issues.
`get_site_timeline`	read	What RankX AI changed on a Website and when, merged onto one time axis. It states its own blind spots on every response: an empty result means no record, never nothing happened.
`list_page_opportunities`	read	The pages with the most to gain from improvement, each with one reason (losing clicks, losing rank, low click-through rate, an AI citation gap or staleness) and the evidence behind it. An empty list is not a clean bill of health, because each reason says when it could not be checked.
`list_tasks`	read	The Website's Tasks board, with title, status, category and opportunity score. Dismissed tasks are excluded unless you ask for them.
`propose_page_optimisation`	spend	Reads a live page, plans the smallest set of changes the evidence supports and rewrites those sections for a person to accept or reject one by one. It spends credits and never changes the website, and a section carrying the page's ranking terms can be protected so it is only added to.
`revert_page_optimisation`	publish	Puts a page back to exactly what it said before an improvement was applied, from the copy RankX AI recorded before writing, and refuses if the page has changed too much since to do that safely.
`revert_task_fix`	publish	Undoes a change apply_task_fix made, restoring the exact values RankX AI recorded before writing. Free, and it dry-runs by default: you see which fields go back to which values before anything is touched. Needs the run id apply_task_fix returned.
`start_site_audit`	spend	Starts a Website Audit, either a full crawl or a single-page quick check. Dispatch and poll: it returns a job id immediately and crawls take minutes.

The table above is generated from RankX AI itself rather than written by hand, as at 30 September 2026 (source b27dec96). When the product changes, this page changes with it.

Running an audit

start_site_audit is the first dispatch-and-poll pair. It returns a job id immediately and the crawl takes minutes; poll get_site_audit_status until it reports complete, then read the findings with get_site_audit_issues.

Two modes: a full crawl, or a single-page quick check. It spends credits per page crawled, and its own description carries the current price. This documentation does not print prices, because rates in RankX AI are versioned and republishable.

get_site_audit_issues returns the most recent completed audit only, with severity, category, affected page counts and fix guidance, plus the overall score and crawl statistics.

A check that did not run is reported as not assessed, never as passed. Three audit paths exist, each answering its own set of checks, and RankX AI records the coverage per check rather than inferring it, so a pass in the result is always a check that ran. See what "a check did not run" means.

The Tasks board

list_tasks reads it, ordered by opportunity score rather than by category. Dismissed tasks are excluded unless you ask for them.

create_task is additive only, and it deduplicates: pass the source that prompted the task, and if an open task already tracks that source, the existing task is returned rather than a copy. This is what stops an assistant running the same analysis twice and producing two boards.

apply_task_fix changes something outside RankX AI, as do the page-improvement tools below. It applies a task's recommended fix to a connected WordPress site, currently the SEO title and meta description, and it carries the publish scope for that reason rather than sitting with the rest of the group.

It dry-runs by default. The dry run returns the exact before and after, plus a run id. Show the diff to the person, and only if they agree call again with the dry run switched off and that run id. Several tasks often point at one page: the diff says how many the change resolves, and they are resolved together for a single charge.

Page improvements

Four tools take one page from "worth improving" to a live change, with a person deciding each section in between.

list_page_opportunities finds the pages. Each comes with one reason (losing clicks, losing rank, a low click-through rate for its position, an AI citation gap or staleness) and the evidence behind it, including the denominator. An empty list is not a clean bill of health: every reason has a precondition, a decline needs about 20 clicks in a 28-day window before it means anything, and the response says which reasons could not be checked and why.

propose_page_optimisation writes the proposal. It reads the live page, plans the smallest set of changes the evidence supports and rewrites those sections. It spends credits, and its own description carries the price, but it never changes the website. A section carrying the page's ranking terms can be protected, so it can only be added to, never rewritten. It runs in the background: poll get_page_optimisation until the state is proposed.

decide_page_optimisation records the person's decision, section by section, after they have seen each before and after. Nothing rejected or left undecided is ever written.

apply_page_optimisation writes only what was accepted, free, because the proposal was already charged for. It reads the page fresh and refuses any section edited on the site since the suggestion was made, rather than overwriting that edit. revert_page_optimisation puts the page back to exactly what it said before, from the copy RankX AI recorded before writing, and refuses if the page has changed too much since to do that safely.

These tools do not dry-run the way the WordPress edits do. The safeguard is the decision step: the proposal is the preview, and only accepted sections are written. Once an improvement has been live for 28 days, get_page_optimisation reports what moved.

The change timeline

get_site_timeline is the correlation axis, and it is the tool most integrations forget exists. It merges onto one time axis every change RankX AI made to the site, every article published, every audit completed and every task finished, newest first.

Use it to explain a movement rather than to find one: fetch the traffic or ranking change first, then ask the timeline what happened around that date.

It states its own blind spots on every response, not just an empty one, and that is deliberate: shown only when empty, a caveat reads as an excuse. The timeline is a record of what RankX AI did, not a history of the website. An edit made directly in WordPress, a plugin update, a hosting incident and a change at a search engine are all invisible to it.

So an empty result means "we have no record", never "nothing happened", and an assistant reporting it should pass that caveat on rather than presenting the timeline as complete.

Its counts describe the match, not the returned slice: the summary is what gets quoted to a person while the table is only what fitted.

Credits

Both credit tools are free to call, and calling them is the difference between proposing work and proposing work someone can afford.

get_credit_balance returns credits available now, credits held by work in flight, the plan and its monthly allowance, any trial state, when unspent grants expire, and on a client-scoped credential the ceiling set for that client. RankX AI instructs every connected assistant to call it before proposing anything that spends, because a price with nothing to weigh it against is not a decision.

get_credit_usage answers "where did my credits go" over a period, grouped by action or by Website. Two properties make it trustworthy:

Refunded work nets to zero and never reads as spend. The wallet reserves before the work and releases in full on failure, so a failed action leaves no spend behind it.

Platform-funded onboarding writes no ledger rows, so the free setup package cannot inflate the figure.

Action grouping carries no client dimension, so a client-scoped credential is refused it and pointed at Website grouping rather than being served an account-wide total it should not see.

Example prompts

"Start a site audit on my main website. Tell me what it will cost first, then poll until it finishes and give me the issues by severity."

"Show me the top ten tasks by opportunity score, and tell me which of them point at the same page."

"Apply the SEO title fix for task X. Dry run it first and show me the exact before and after."

"Which of my pages have the most to gain from an improvement? Propose one for the top page, then show me every section before and after."

"My Search Console clicks dropped around the 14th. What does the site timeline say happened around then, and what can it not see?"

"What is my credit balance, and how much of it is held by work in flight?"

"Where did my credits go last month, grouped by website?"

Where to go next

Running an audit for the workflow.
Tasks for the board itself.
Credits and metering for the wallet model and the four refusals.

Last updated 1 October 2026