Skip to main content
Glama

CrunchJunkie

by io.crunchjunkie.app
OverviewDiscussionsAdmin

manage_competitors

Add or remove competitor brands tracked in a client's AI Visibility (competitors set the Share-of-Voice denominator), optionally with a website domain (used by the GEO-audit crawler benchmark, which always reads the project's own list) or brand aliases (alternate spellings counted as the same brand). Every market tracks the project's competitors unless it has its own list. market changes one market's own list (its first change starts from the project's list); without it the project's list changes, which every market without its own list tracks (the preview names those markets); market plus resetMarket:true puts a market back on the project's list. A market's list affects that market's Share of Voice only. Changing competitors rebases Share of Voice, so an internal timeline note is written. Requires MCP write actions; without confirm:true it returns a preview.

Input Schema

NameRequiredDescriptionDefault
addNoCompetitor brand names to start tracking. A URL or a domain is tracked under its bare domain ("https://www.example.com/" → "example.com") with that domain as its website; a brand name is preferred, since answers are matched by name.
marketNoA market of the project, as a locale ("de-DE", "en-US"; marketsInWindow of get_ai_visibility_metrics lists them): change that market's own competitors only. Omit to change the project's competitors.
removeNoCompetitor brand names to stop tracking (case-insensitive match).
aliasesNoCanonical brand name → alternate spellings counted as the same brand, e.g. { "Peec AI": ["Peec"] }. With market: only that market's competitors (the client's own aliases are the project's).
confirmNoSet true to apply. Omit for a preview. With confirm:true, also pass the preview's previewToken.
domainsNoCompetitor name → website domain, e.g. { "Peec AI": "peec.ai" }. Merged into the tracked set.
clientIdNoClient id (from list_clients) — alternative to projectId.
projectIdNoAI-visibility project id.
resetMarketNoWith market: true puts the market back on the project's competitors (its own list, websites and aliases are cleared). add, remove, domains and aliases are then ignored.
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. Changed4 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
    • addedInput schema / properties / aliases / propertyNames
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / domains / propertyNames
      Added value: +{
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / add / description
      Previous value: -"Competitor brand names to start tracking. A URL or a domain is tracked under its bare domain (\"https://www.example.com/\" → \"example.com\") with that domain as its website; give the brand name instead when you know it, since answers are matched by name."New value: +"Competitor brand names to start tracking. A URL or a domain is tracked under its bare domain (\"https://www.example.com/\" → \"example.com\") with that domain as its website; a brand name is preferred, since answers are matched by name."
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only say non-readonly and non-destructive; the description goes well beyond them by disclosing the write-permission requirement, the preview/confirm gate, the rebasing of Share of Voice, the internal timeline note, and exactly what resetMarket clears (own list, websites, aliases). That is the kind of consequence information an agent needs before mutating state.

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?

Purpose and scope come first, then the market/reset logic, then the confirm requirement — well front-loaded. The middle sentences are dense with parentheticals (crawler benchmark, aliases, preview naming markets) that make it slower to parse than it needs to be, though nothing is truly 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?

Ten parameters, nested objects, no output schema and an involved confirm/preview protocol — yet the description covers the branching semantics, side effects, and the confirm flow's requirement for previewToken. An agent could invoke this correctly from the description plus schema alone.

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; the description still adds real meaning by tying `market` to inheritance behavior, noting that a market's first change starts from the project's list, and clarifying that domains/aliases merge into the tracked set. The only gap is that individual parameters like `clientId`/`projectId` are not discussed in prose.

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

Purpose4/5

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

Opens with a specific verb+resource: add or remove competitor brands tracked in a client's AI Visibility, and even explains their role (Share-of-Voice denominator). That is far more than a restatement of the name. It stops short of 5 because it never distinguishes itself from the sibling manage_rank_competitors, which an agent could easily confuse with this tool.

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?

Explicitly explains the two operating modes (project-level list vs a single market's own list), how a market inherits the project list, and how `resetMarket` reverts. The preview-then-confirm flow is stated as a precondition. No guidance on when to prefer management over a read tool like get_brand_perception, and no cross-reference to manage_rank_competitors.

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

All CrunchJunkie toolsInspect
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