Compare AI visibility across multiple entities side-by-side. Probes each entity (your brand + N competitors) with ai_visibility_check, ranks by score, surfaces which is most/least recognized. Useful for competitive AI-marketing audits: "does Claude know about us as well as our competitors?". Retu...
AI agents call scan_competitor_ai_presence to retrieve information from Mcp Powo without modifying anything — typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
models | array | — | Which models to probe. Supported: "workers-ai" (free default), "anthropic" (requires _apiKey). Omit for just workers-ai. |
_apiKey | string | — | Optional Anthropic API key — only if "anthropic" is in models. Passed to api.anthropic.com per probe. |
context | string | — | Optional shared context applied to every probe (e.g. "B2B SaaS", "Boston restaurant"). Disambiguates common names. |
entities | array | Yes | Array of 2-8 entities to compare (brand/business/product names). First entry treated as the "subject" for narrative; rest are competitors. |
Parameters from the server's own tool schema.
This is a Read operation: it queries AI visibility data and ranks competitors by recognition scores. There is no creation, modification, deletion, or irreversible action. No code execution or external operations are triggered beyond data retrieval. The worst-case misuse is obtaining competitive intelligence, which has low blast radius compared to Write/Execute/Destructive operations.
From the tool's definition The tool 'scan_competitor_ai_presence' retrieves and compares AI visibility metrics across entities using 'ai_visibility_check' probes.
Attacks that exploit this kind of access
Compare AI visibility across multiple entities side-by-side. Probes each entity (your brand + N competitors) with ai_visibility_check, ranks by score, surfaces which is most/least recognized. Useful for competitive AI-marketing audits: "does Claude know about us as well as our competitors?". Returns ranked list with score, confidence, signal density per entity. It is categorised as a Read tool in the Mcp Powo MCP Server, which means it retrieves data without modifying state.
scan_competitor_ai_presence accepts 4 parameters: models, _apiKey, context, entities. Required: entities. The full parameter table on this page comes from the server's own tool schema.
Register the Mcp Powo MCP server in PolicyLayer and add a rule for scan_competitor_ai_presence: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mcp Powo. Nothing to install.
scan_competitor_ai_presence is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the scan_competitor_ai_presence rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for scan_competitor_ai_presence. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
scan_competitor_ai_presence is provided by the Mcp Powo MCP server (pipeworx-io/mcp-powo). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Every MCP server has a record like this.
Type a name, get the same breakdown: verified identity, auth posture, risk grade, capabilities, recommended policy.
Teams ship this data inside their own products. See what a licence covers →