GEO MCP by DigestSEO

Track a brand

track_brand

Idempotent

Create a tracked brand with starter buyer-intent prompts to monitor AI citations across search engines.

Instructions

Create a local tracked brand and starter buyer-intent prompts; uses Claude Haiku when configured, otherwise three generic prompts. Example: brand_id='acme', name='Acme', domain='acme.com'. Call refresh_brand next.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Brand display name.
`domain`	Yes	Primary domain, e.g. 'acme.com'.
`aliases`	No	Additional names that count as brand mentions.
`brand_id`	Yes	New stable brand ID, e.g. 'acme'.
`category`	No	Market/category for prompt generation.
`competitors`	No	Competitor domains to compare.
`prompt_count`	No	Buyer-intent prompts to create.
`exclude_terms`	No	Bare terms to ignore in mention matching; the full domain still matches.
`refresh_frequency`	No	Worker cron cadence; 'manual' disables cron scans. Local stdio stores this setting only.	weekly

Output Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	No
`reason`	No
`seeded`	Yes
`brand_id`	Yes
`next_steps`	Yes
`competitors`	No
`prompt_source`	No
`prompts_inserted`	No
`refresh_frequency`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.3.23Sep 23, 2026

changedInput schema / properties / aliases / description

Previous value: -"Extra terms that always count as a brand mention (product names, abbreviations)."New value: +"Additional names that count as brand mentions."

changedInput schema / properties / brand_id / description

Previous value: -"Stable identifier to assign to the new tracked brand."New value: +"New stable brand ID, e.g. 'acme'."

changedInput schema / properties / category / description

Previous value: -"Optional product or market category for prompt generation."New value: +"Market/category for prompt generation."

changedInput schema / properties / competitors / description

Previous value: -"Optional competitor domains to include in visibility analysis."New value: +"Competitor domains to compare."

changedInput schema / properties / domain / description

Previous value: -"Primary domain of the brand, such as acme.com."New value: +"Primary domain, e.g. 'acme.com'."

changedInput schema / properties / exclude_terms / description

Previous value: -"Terms suppressed from bare-word matching — for brand names that are everyday words (\"Monday\", \"Notion\"). The full domain still matches."New value: +"Bare terms to ignore in mention matching; the full domain still matches."

changedInput schema / properties / name / description

Previous value: -"Display name of the brand to track."New value: +"Brand display name."

changedInput schema / properties / prompt_count / description

Previous value: -"Number of buyer-intent prompts to generate for the brand."New value: +"Buyer-intent prompts to create."

changedInput schema / properties / refresh_frequency / description

Previous value: -"Refresh cadence used by self-hosted Worker cron scheduling. Choose 'manual' to disable cron scans while keeping the brand, prompts, and history. Local stdio stores this setting but does not run a background scheduler."New value: +"Worker cron cadence; 'manual' disables cron scans. Local stdio stores this setting only."

Changed3 schema fields changedv0.3.19Sep 22, 2026

changedInput schema / properties / refresh_frequency / description

Previous value: -"Refresh cadence used by self-hosted Worker cron scheduling. Local stdio stores this setting but does not run a background scheduler."New value: +"Refresh cadence used by self-hosted Worker cron scheduling. Choose 'manual' to disable cron scans while keeping the brand, prompts, and history. Local stdio stores this setting but does not run a background scheduler."

changedInput schema / properties / refresh_frequency / enum

Previous value: -[
-  "daily",
-  "weekly"
-]New value: +[
+  "daily",
+  "weekly",
+  "manual"
+]

changedOutput schema / properties / refresh_frequency / enum

Previous value: -[
-  "daily",
-  "weekly"
-]New value: +[
+  "daily",
+  "weekly",
+  "manual"
+]

Changed2 schema fields changedv0.3.15Sep 20, 2026

addedInput schema / properties / refresh_frequency

Added value: +{
+  "default": "weekly",
+  "description": "Refresh cadence used by self-hosted Worker cron scheduling. Local stdio stores this setting but does not run a background scheduler.",
+  "enum": [
+    "daily",
+    "weekly"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / refresh_frequency

Added value: +{
+  "enum": [
+    "daily",
+    "weekly"
+  ],
+  "type": "string"
+}

First observedv0.3.2Aug 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond those: it mentions the model selection behavior ('uses Claude Haiku when configured, otherwise three generic prompts'), the local scope ('local tracked brand'), and the follow-up action. No contradictions with the annotations.

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

Conciseness5/5

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

The description is two sentences plus a short example: purpose, model behavior, example values, and next-step instruction. Every segment carries weight, no filler, and the core action is front-loaded.

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

Completeness4/5

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

For a tool with 9 parameters, annotations, and an output schema, the description covers purpose, a usage example, model configuration, and the next step. It does not explicitly clarify when to use alternatives such as update_brand or generate_prompts, nor explain 'starter' prompt semantics, but the high schema coverage and output schema carry much of the load.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3 even without parameter info in the description. The description provides a compact example mapping brand_id, name, and domain, but adds little beyond what the schema already documents; it does not explain parameter interactions like prompt_count or exclude_terms.

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?

The description states a specific action ('Create a local tracked brand') and a concrete additional output ('starter buyer-intent prompts'), which distinguishes it from siblings like refresh_brand, update_brand, and generate_prompts. The example clarifies the exact resource being created.

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?

Clear workflow context is provided: it creates a brand plus prompts, and then explicitly instructs 'Call refresh_brand next.' There is no explicit 'use this instead of X' guidance or exclusions, but the purpose is unambiguous enough for an agent to know when to select it.

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

Deploy Server