XeoRank

update_content_brief

Save work on a brief: the outline (JSON list of {heading, level, notes}), the draft in markdown (exactly one H1 = the title), title, intent, kind, status or notes. Saving a draft moves the brief to 'draft' and clears the previous score — call score_content_draft again. Set refresh_evidence=true after compute_content_gaps, sync_search_console or run_visibility_scan to re-collect the evidence (refresh_serp=true also re-fetches the live Google results). Published on a platform other than WordPress? Pass published_url (the live URL) — the brief becomes 'published' and XeoRank tracks its Search Console results against the score.

Input Schema

Name	Required	Description
`kind`	No	create \| optimize
`notes`	No	Notes
`title`	No	Title
`intent`	No	Search intent
`status`	No	idea \| brief \| draft \| review \| published \| archived
`outline`	No	JSON array: [{heading, level, notes}]
`brief_id`	Yes	The brief ID
`draft_md`	No	The full draft in markdown
`author_draft`	No	HUMAN-FIRST PATH: the author's own rough version, verbatim (typed or a dictation transcript). Save it before you touch it. Then structure and tighten it keeping their sentences; score_content_draft reports how much of their text survived and flags opinions that are not theirs. Also grows the brand's voice corpus.
`human_inputs`	No	JSON object of the author's interview answers, e.g. {"expected_vs_happened": "...", "proof": "...", "pushback": "...", "got_wrong": "...", "who_for": "...", "dont": "...", "one_sentence": "..."}. Their words are the only source of opinions and first person in the draft; score_content_draft credits answers the draft uses.
`refresh_serp`	No	With refresh_evidence: fetch the live Google results again
`published_url`	No	The live URL when the piece was published outside WordPress (starts outcome tracking)
`refresh_evidence`	No	Re-collect the evidence bundle from stored data

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 7, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavioral facts beyond the annotations: saving a draft transitions status to 'draft' and clears the previous score (a destructive-ish side effect), and supplying published_url flips the brief to 'published' and starts Search Console tracking. Annotations cover safety profile; the description covers side effects and state transitions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose before layering conditional side effects, and each sentence carries actionable content. Slightly dense with several clauses packed into the last two sentences, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a full parameters schema but no output schema and 13 params, the description covers state transitions, score invalidation, evidence-refresh triggers, and the off-WordPress publish path. An agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the outline's shape, the 'exactly one H1 = title' rule for draft_md, and the precise effect of refresh_evidence/refresh_serp/published_url. It goes beyond the terse inline schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Save work on a brief') and resource, and enumerates the savable fields. It is clearly differentiated from sibling create_content_brief (new brief) and publish_content_brief (publish action).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit conditional guidance: call score_content_draft again after saving a draft, set refresh_evidence=true after compute_content_gaps/sync_search_console/run_visibility_scan, and pass published_url when publishing off WordPress. Alternatives and triggers are named, not inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All XeoRank tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?