Skip to main content
Glama

create_content_brief

Generate an evidence-grounded content brief for one tracked prompt: it reads the recent answers for the prompt, the pages the engines cited and the searches they ran, checks the brand's own Search Console (when connected) for a page already within Google's top 20 for those searches, and writes a page plan (target question, recommendations, structure, schema to add, and proof to include: the kind of proof and its genuine source, never a figure to publish) with the evidence and a refresh-or-new verdict. When the recent answers show no real gap, it says so instead of writing a brief. It spends AI on the workspace's own key or Managed AI, not against the scan allowance. Requires write actions and "Allow actions that spend AI"; counts toward 20 assistant-started scans, briefs and rankings refreshes per workspace per day. Without confirm:true it returns a preview. Saved briefs are read with get_content_brief.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "promptId": "<promptId>"
    },
    "name": "create_content_brief"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagNoWith search: only answers of prompts carrying this tag.
daysNoWith search: the window in whole UTC days (default 30).
engineNoWith search: only that engine's answers (the channel id get_ai_visibility_metrics names).
searchNoScope the brief to ONE fan-out search of that prompt (a search the engines ran for it, as get_query_fanouts lists them): it is built on the answers that ran that search in the window, saved beside the prompt's own brief (one open brief per search), and read back with get_content_brief's search. Omit for the prompt's own brief over every answer.
confirmNotrue generates the brief. Omit to preview. With confirm:true, also pass the preview's previewToken.
promptIdYesThe tracked prompt to write a brief for (id from list_prompts or get_content_gaps).
promptTypeNoWith search: only answers of shopping prompts, or only of the others (the fan-outs page's type filter).
previewTokenNoWith confirm:true: the previewToken from this tool's preview (valid 15 minutes, once, for exactly the previewed arguments).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed1 schema field changed
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true to generate the brief. Omit to preview. With confirm:true, also pass the preview's previewToken."New value: +"true generates the brief. Omit to preview. With confirm:true, also pass the preview's previewToken."
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Exceptional disclosure beyond annotations: AI spend source (workspace key or Managed AI, not scan allowance), the 20-per-day workspace quota for assistant-started scans/briefs/refresh, the write-actions and 'Allow actions that spend AI' prerequisites, preview token validity (15 min, single-use, argument-bound), and the one-open-brief-per-search constraint. Fully consistent with readOnlyHint=false and destructiveHint=false.

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-loaded with the verb and resource, and nearly every clause carries distinct information. The opening sentence is long and parenthetical-heavy, which costs some readability, but there is little genuine filler.

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?

For a complex, mutation-plus-spend tool with no output schema, the description covers prerequisites, quota, billing, preview mechanics, storage/discovery of results, and the negative outcome case. An agent has everything needed to call it correctly or decide not to.

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 baseline is 3, but the description adds real semantics: it explains the search parameter's scoping behavior and where that brief is stored, and ties previewToken to confirm:true via the preview flow. The promptId sourcing hint also adds value.

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 (generate) and resource (evidence-grounded content brief) scoped to one tracked prompt, then enumerates exactly what it reads (recent answers, cited pages, searches, Search Console) and what it writes (page plan, evidence, refresh-or-new verdict). It explicitly distinguishes itself from get_content_brief, the read-side sibling.

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

Usage Guidelines4/5

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

Clearly explains the preview-then-confirm workflow, names get_content_brief for reading saved briefs, and notes the no-gap case where it declines to write a brief. It does not explicitly compare against get_content_gaps or suggest_prompts beyond citing them as id sources, so it stops short of full sibling routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources