The Peec AI MCP Server provides 38 tools to monitor and analyze brand visibility, sentiment, and citations across AI models like ChatGPT and Perplexity.
Data Retrieval
List projects, brands, prompts, tags, topics, AI models, and model channels
Browse and filter AI chat interactions; retrieve full chat content (sources, cited URLs, brands, messages, queries)
View AI-generated suggestions for prompts, topics, and brands
Access a project's brand profile (industry, identity, markets, audience)
Analytics Reports
Brand visibility: visibility ratio, share of voice, mention count, sentiment, and average position
Domain citations: retrieval rate, citation rate, and classification (OWN, COMPETITOR, EDITORIAL, etc.)
URL citations: individual URL performance, citation/retrieval counts, and URL classification
URL content: scraped markdown of any cited source URL
All reports support filtering by prompt, model, tag, topic, date, country, and chat
Query Analysis
Search queries generated by AI models when answering prompts
Shopping/product queries generated by AI models
Write Operations (requires PEECAI_ALLOW_WRITES=true)
Create, update, and delete brands, prompts, tags, and topics
Accept or reject AI-generated suggestions
Set or replace a project's brand profile
MCP Resources & Prompt Templates
Static reference data accessible via URI templates
Guided analytical workflows (e.g., brand visibility analysis, competitive gap analysis)
Supports tool annotations, progress notifications, structured logging, and cancellation
Provides analytics and insights for brand visibility, sentiment, citations, and search queries within Perplexity AI, including metrics such as retrieval rates, citation counts, domain classifications, and brand mention analytics across Perplexity-generated responses.
Note: This is an unofficial community project, not affiliated with or endorsed by Peec AI. It requires a Peec AI account and API key.
API Beta: The Peec AI API is currently in beta — endpoints, payloads, and responses may change. Access is limited to Enterprise customers.
Peec AI tracks how brands appear in AI-generated answers. This MCP server gives any MCP-compatible client direct access to that data — 38 tools covering projects, brands, prompts, chats, query analysis, analytics reports, source content, brand profiles, and full CRUD operations.
Key capabilities:
Query brand visibility, sentiment, and position across AI models
Analyze which domains and URLs get cited in AI responses
Inspect individual chat interactions with full source attribution
Slice data by model, prompt, category tag, topic, country, or date
Create, update, and delete brands, prompts, tags, and topics (opt-in)
Review and act on AI-generated prompt and topic suggestions
Related MCP server: ai-visibility-mcp
Sign up at app.peec.ai and create an API key under Settings > API Keys.
claude mcp add --transport stdio peecai -- npx -y mcp-server-peecaiSet environment variables:
export PEECAI_API_KEY="your-api-key"
export PEECAI_PROJECT_ID="your-project-id" # optional defaultAdd to your claude_desktop_config.json:
{
"mcpServers": {
"peecai": {
"command": "npx",
"args": ["-y", "mcp-server-peecai"],
"env": {
"PEECAI_API_KEY": "your-api-key",
"PEECAI_PROJECT_ID": "your-project-id"
}
}
}
}Add to .vscode/mcp.json in your workspace:
{
"servers": {
"peecai": {
"command": "npx",
"args": ["-y", "mcp-server-peecai"],
"env": {
"PEECAI_API_KEY": "your-api-key",
"PEECAI_PROJECT_ID": "your-project-id"
}
}
}
}Confirm the peecai server is connected — in Claude Code run /mcp, in VS Code/Cursor check the MCP server status in the output panel.
list_projects — List all projects for the company.
Returns: project IDs, names, statuses (CUSTOMER = active, PITCH = demo)
Parameters: limit, offset
list_brands — List tracked brands with their associated domains.
Parameters: project_id, limit, offset
list_prompts — List monitored search prompts.
Returns: prompt messages, tags, topics, user location, search volume
Parameters: project_id, topic_id, tag_id, limit, offset
list_tags — List category tags for a project.
Parameters: project_id, limit, offset
list_topics — List topic groupings for a project.
Parameters: project_id, limit, offset
list_models — Deprecated; prefer list_model_channels. List tracked AI models (ChatGPT, Perplexity, etc.).
Returns: model IDs and active status
Parameters: project_id, limit, offset
list_model_channels — List model channels (stable IDs grouping one or more models, e.g. openai-0, perplexity-0).
Returns: channel ID, description, currently active model, active status
Parameters: project_id, limit, offset
list_chats — List AI chat interactions with optional date and dimension filtering.
Returns: chat IDs, prompt/model/model_channel refs, dates
Parameters: project_id, start_date, end_date, brand_id, prompt_id, model_id, model_channel_id, limit, offset
get_chat_content — Get full content of a specific chat.
Returns: sources (URLs, domains, citation counts), brands mentioned, messages, queries, products
Parameters: chat_id, project_id
list_prompt_suggestions — List AI-generated prompt suggestions.
Parameters: project_id, topic_id, limit, offset
list_topic_suggestions — List AI-generated topic suggestions.
Parameters: project_id, limit, offset
list_brand_suggestions — List AI-generated brand suggestions.
Returns: suggestion ID, name, domains, chat_count
Parameters: project_id, limit, offset
get_project_profile — Read the project's brand profile (occupation, industry, brand identity, target markets, audience distribution).
Returns: profile object or null if not yet profiled
Parameters: project_id
All report tools support dimensions for multi-level breakdowns: prompt_id, model_id, model_channel_id, tag_id, topic_id, date, country_code, chat_id. Date filtering via start_date / end_date (YYYY-MM-DD). Server-side filtering via filters parameter (field, operator: "in" | "not_in", values).
get_brands_report — Brand analytics per brand.
Metric | Description |
| Ratio 0–1 (visibility_count / visibility_total) |
| Score 0–100, 50 = neutral |
| Average rank when mentioned, lower = better |
| Share of voice 0–1 (proportion of total mentions) |
| Number of times the brand was mentioned |
get_domains_report — Domain-level analytics.
Metric | Description |
| Share of chats retrieving this domain (0–1) |
| Average citations per retrieval |
|
|
get_urls_report — URL-level analytics.
Metric | Description |
| Number of chats retrieving this URL (replaces deprecated |
| Total citations across all chats |
| Average citations per retrieval |
|
|
get_url_content — Get the scraped markdown content of a source URL discovered via get_urls_report.
Returns: content (markdown, null while scraping pending), title, domain, channel_title, classification, url_classification, content_length, truncated, content_updated_at
Parameters: url, project_id, max_length (1–20,000,000, default 100,000)
If stored content exceeds max_length, truncated=true — re-request with a larger max_length to get more.
search_queries — Get search queries AI models generated when answering prompts.
Parameters: project_id, start_date, end_date, filters, limit, offset
shopping_queries — Get shopping/product queries AI models generated.
Parameters: project_id, start_date, end_date, filters, limit, offset
Write tools are disabled by default for safety. Enable them by setting PEECAI_ALLOW_WRITES=true.
When disabled, these tools are completely invisible — they don't appear in tools/list and cannot be called by any client.
Entity | Create | Update | Delete |
Brands |
|
|
|
Prompts |
|
|
|
Tags |
|
|
|
Topics |
|
|
|
Suggestions | Accept | Reject |
Prompt suggestions |
|
|
Topic suggestions |
|
|
Brand suggestions |
|
|
set_project_profile — Replace the project's brand profile (occupation, industry, brand identity, target markets, audience distribution). Full overwrite; audienceDistribution percentages must sum to 100. Triggers a background refresh of prompt suggestions.
Delete operations are soft-deletes and irreversible through the API. Delete tools carry destructiveHint: true in their MCP annotations, causing clients like Claude Code to require explicit user approval before execution.
Tool type | Read-only | Idempotent | Destructive |
All read tools (19) | Yes | Yes | No |
Create (4) | No | No | No |
Update (4) | No | Yes | No |
Delete (4) | No | Yes | Yes |
Accept suggestion (3) | No | No | No |
Reject suggestion (3) | No | Yes | No |
| No | Yes | Yes |
MCP resources provide reference data that clients can fetch without a tool call.
Resource | Type | Description |
| Static | List all projects |
| Template | Brands for a project |
| Template | Tags for a project |
| Template | Topics for a project |
| Template | AI models for a project |
| Template | Prompts for a project |
Resource templates support listing — clients can enumerate available resources across all projects.
Guided analytical workflows available as MCP prompts. All prompts support project_id autocompletion.
Prompt | Description |
| Analyze brand visibility, sentiment, and position across AI models |
| Compare own brand vs competitors across prompts and models |
| Analyze domain and URL citations in AI responses |
"List my Peec AI projects"
"Show brand visibility for the last 30 days"
"Which domains get cited most in AI search results?"
"Compare brand sentiment across ChatGPT and Perplexity"
"Show me the full chat content for chat ID abc-123"
"Get URL report broken down by AI model and country"
"What search queries do AI models use when answering my prompts?"
"Create a brand 'My Brand' with domain mybrand.com"
"Add a new prompt: 'best CRM software 2025' for country DE"Variable | Required | Description |
| Yes | API key from app.peec.ai |
| No | Default project ID — saves repeating it in every tool call |
| No | Set to |
This server implements the MCP 2025-11-25 specification:
Structured content — list tools return structuredContent alongside text for type-safe client parsing
Tool annotations — readOnlyHint, destructiveHint, idempotentHint on every tool
Progress notifications — report tools send progress updates when the client provides a progressToken
Structured logging — API errors are sent as MCP log notifications with endpoint, status, and message context
Prompt completions — project_id argument supports autocompletion via completable()
Resource templates — with list callbacks for enumerating resources across projects
Cancellation support — all tools forward the MCP AbortSignal to API calls
The Peec AI API is in beta and may change. A drift detection script compares the live OpenAPI spec against a committed snapshot:
npm run check:api-driftNo drift: exit code 0, snapshot is current
Drift detected: exit code 1, shows a diff of changes
No API key is required — the OpenAPI spec is publicly accessible.
Node.js >= 22
npm
npm install # Install dependencies
npm run build # Compile TypeScript to dist/
npm run dev # Watch mode — recompile on changes
npm test # Run unit tests (372 tests)
npm run test:watch # Run tests in watch mode
npm run test:integration # Run integration tests (requires PEECAI_API_KEY)
npm run check:api-drift # Check for API spec changesIntegration tests hit the live Peec AI API and are skipped by default in npm test.
# Read-only smoke test (all 19 read tools + prompts + resources)
PEECAI_API_KEY=xxx npm run test:integration
# Full CRUD round-trip (requires a test project + write access)
PEECAI_ALLOW_WRITES=true PEECAI_TEST_PROJECT_ID=or_xxx npm run test:integrationsrc/
├── index.ts # Server entry point, tool/resource/prompt registration
├── api-client.ts # HTTP client for Peec AI Customer API
├── types.ts # TypeScript interfaces for API responses
├── schemas.ts # Zod output schemas for structured content
├── util.ts # Validation, date handling, MCP response helpers
├── prompts.ts # MCP prompt templates (guided workflows)
└── tools/ # One file per MCP tool (or tool group)
├── projects.ts # list_projects
├── brands.ts # list_brands
├── prompts.ts # list_prompts
├── tags.ts # list_tags
├── topics.ts # list_topics
├── models.ts # list_models
├── model-channels.ts # list_model_channels
├── chats.ts # list_chats
├── chat-content.ts # get_chat_content
├── prompt-suggestions.ts # list_prompt_suggestions
├── topic-suggestions.ts # list_topic_suggestions
├── brand-suggestions.ts # list_brand_suggestions
├── project-profile.ts # get_project_profile, set_project_profile
├── report-brands.ts # get_brands_report
├── report-domains.ts # get_domains_report
├── report-urls.ts # get_urls_report
├── url-content.ts # get_url_content
├── queries-search.ts # search_queries
├── queries-shopping.ts # shopping_queries
├── write-brands.ts # create/update/delete brand
├── write-prompts.ts # create/update/delete prompt
├── write-tags.ts # create/update/delete tag
├── write-topics.ts # create/update/delete topic
└── suggestion-actions.ts # accept/reject suggestionsBuilt by Tobias Hein at artaxo — a digital marketing agency specializing in AI Search Optimization.
Get brand analytics report per brand. Metrics: visibility (visibility_count/visibility_total), share_of_voice (0-1), mention_count, sentiment (0-100 scale, 50=neutral), position (avg rank when mentioned, lower=better). Returns up to limit results (default: 100). Use brand_id shortcut or filters array for server-side filtering. Supports date filtering and dimensional breakdowns. Without date filters, returns data across all available dates. Empty results may indicate the project has no report data for the given time range or filters — try a broader date range or fewer filters.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| start_date | No | Start date (YYYY-MM-DD). Omit for no lower bound. | |
| end_date | No | End date (YYYY-MM-DD). Omit for no upper bound. | |
| dimensions | No | Breakdown dimensions. Each adds a grouping level to results: prompt_id (by search prompt), model_id (by AI model), model_channel_id (by model channel, e.g. openai-0/perplexity-0), tag_id (by category tag), topic_id (by topic group), date (by date), country_code (by country), chat_id (by individual chat). Multiple dimensions can be combined. | |
| brand_id | No | Convenience filter for a single brand (converted to server-side filter). Use list_brands to find IDs. | |
| filters | No | Server-side filters. Multiple filters are AND'd together. | |
| limit | No | Max results (1-10000, default: 100) | |
| offset | No | Results to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, indicating safe read operation. Description adds beyond annotations: default date behavior (all available dates), empty result explanation, limit default/max. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single focused paragraph that front-loads purpose and key metrics, then covers parameters and troubleshooting. Every sentence adds value, no redundancy. Could be slightly more structured with bullet points but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and complexity, description covers key aspects: metrics, filtering, dimensions, default date range, limit/max, and error handling. Slightly misses offset pagination behavior but overall nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all parameters documented). Description adds significant value by explaining metrics (visibility, share_of_voice, sentiment scale, position interpretation) and dimension meanings (e.g., prompt_id by search prompt, model_id by AI model). This goes beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves brand analytics reports per brand with specific metrics. It's specific and uses clear verb-resource combination. However, it doesn't explicitly differentiate from sibling reporting tools like get_domains_report or get_urls_report, though the name implies brand focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides guidance on using brand_id shortcut vs filters array, references list_projects and list_brands for ID lookup, and explains empty results behavior with suggestions to broaden date range or reduce filters. Lacks explicit when-not-to-use compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full content of a specific AI chat. Returns sources, brands mentioned, messages, queries, and products.
| Name | Required | Description | Default |
|---|---|---|---|
| chat_id | Yes | Chat ID to retrieve | |
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. |
| Name | Required | Description |
|---|---|---|
| _summary | Yes | Human-readable summary of the result |
| chat | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent hints. The description adds value by specifying the exact data returned (sources, brands, messages, queries, products), which is beyond the annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It efficiently conveys the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description is not required to detail return values. It lists key content types, which is sufficient. The schema covers parameter patterns, so no missing critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra context: project_id is optional and defaults to an environment variable, and it suggests a method to find project IDs. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('full content of a specific AI chat'), clearly stating what the tool does. It lists the returned data types (sources, brands, messages, queries, products), distinguishing it from sibling tools like 'list_chats' or 'get_url_content'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context by stating it returns full chat content, and the parameter description for project_id suggests calling 'list_projects' to find IDs. However, it does not explicitly state when to use this tool versus alternatives or exclude any cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get domain analytics report: retrieval_rate, citation_rate, and retrieved_percentage. Classification values: OWN, CORPORATE, COMPETITOR, EDITORIAL, REFERENCE, INSTITUTIONAL, UGC, OTHER. Returns up to limit results (default: 100). Classification is filtered client-side after retrieval. Use filters array for server-side filtering by model, tag, topic, prompt, domain, URL, or country_code. Without date filters, returns data across all available dates. Empty results may indicate the project has no report data for the given time range or filters.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| start_date | No | Start date (YYYY-MM-DD). Omit for no lower bound. | |
| end_date | No | End date (YYYY-MM-DD). Omit for no upper bound. | |
| dimensions | No | Breakdown dimensions. Each adds a grouping level to results: prompt_id (by search prompt), model_id (by AI model), model_channel_id (by model channel, e.g. openai-0/perplexity-0), tag_id (by category tag), topic_id (by topic group), date (by date), country_code (by country), chat_id (by individual chat). Multiple dimensions can be combined. | |
| classification | No | Filter by domain classification (applied client-side after retrieval). | |
| filters | No | Server-side filters. Multiple filters are AND'd together. | |
| limit | No | Max results (1-10000, default: 100) | |
| offset | No | Results to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, idempotent behavior. The description adds important behavioral details: classification is filtered client-side after retrieval, filters are server-side AND'd, and date range omission returns all data. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs: first states purpose, second covers filtering and edge cases. Fairly concise and front-loaded. Minor redundancy in classification list (already in schema enums) but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains core metrics and behaviors (client/server filtering, date ranges, limit/offset). It briefly mentions empty results. Enough for an agent to use correctly, though output structure could be clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 8 parameters. The description adds value by clarifying client-side classification filtering and the server-side filter structure (AND logic). This exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves domain analytics with specific metrics (retrieval_rate, citation_rate, retrieved_percentage) and lists classification values. It distinguishes from sibling tools like get_brands_report or get_urls_report by focusing on domain-level data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains client-side vs server-side filtering, date range behavior, and empty result interpretation. It lacks explicit alternatives or when-not-to-use guidance, but provides sufficient context for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the scraped markdown content of a source URL. Use the URLs report (get_urls_report) to discover URLs. Returns markdown content plus metadata (title, domain, channel_title, classification, url_classification, content_length, truncated, content_updated_at). If stored content exceeds max_length, the response is truncated and truncated=true — re-request with a larger max_length to get more. Returns 404 if the URL is not tracked by the project.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to fetch content for. Discover URLs via get_urls_report. | |
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| max_length | No | Maximum number of characters of content to return (1-20,000,000). Default 100,000. |
| Name | Required | Description |
|---|---|---|
| _summary | Yes | Human-readable summary of the result |
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return fields (markdown, metadata), truncation behavior (truncated flag, re-request with larger max_length), and 404 for untracked URLs. This adds significant context beyond the annotations (readOnlyHint, etc.), with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences covering purpose, usage guidance, key behaviors, and a special case (404). No unnecessary words; front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a tool with 3 parameters and an output schema. Covers discovery, truncation, and error handling, leaving no gap in understanding usage and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions (100% coverage), and the description enhances them: suggests get_urls_report for url discovery, list_projects for project_id, and explains max_length range and truncation effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves scraped markdown content of a source URL. It references the sibling tool get_urls_report for URL discovery, distinguishing it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using get_urls_report to discover URLs, and explains how to handle truncation by re-requesting with a larger max_length. However, it does not mention when to avoid using this tool (e.g., for chat content) or consider alternatives beyond the one sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get URL analytics report: citation_count (total citations), retrievals (retrieval count), citation_rate. Classification values: HOMEPAGE, CATEGORY_PAGE, PRODUCT_PAGE, LISTICLE, COMPARISON, PROFILE, ALTERNATIVE, DISCUSSION, HOW_TO_GUIDE, ARTICLE, OTHER. Returns up to limit results (default: 100). Classification is filtered client-side after retrieval. Use filters array for server-side filtering by model, tag, topic, prompt, domain, URL, or country_code. Without date filters, returns data across all available dates. Empty results may indicate the project has no report data for the given time range or filters.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| start_date | No | Start date (YYYY-MM-DD). Omit for no lower bound. | |
| end_date | No | End date (YYYY-MM-DD). Omit for no upper bound. | |
| dimensions | No | Breakdown dimensions. Each adds a grouping level to results: prompt_id (by search prompt), model_id (by AI model), model_channel_id (by model channel, e.g. openai-0/perplexity-0), tag_id (by category tag), topic_id (by topic group), date (by date), country_code (by country), chat_id (by individual chat). Multiple dimensions can be combined. | |
| classification | No | Filter by URL classification (applied client-side after retrieval). | |
| filters | No | Server-side filters. Multiple filters are AND'd together. | |
| limit | No | Max results (1-10000, default: 100) | |
| offset | No | Results to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description reinforces this by describing a read operation returning analytics data. It adds transparency about client-side filtering and date range behavior without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that covers all key points. It is not overly verbose, but could be slightly more structured with bullet points for clarity. Nonetheless, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description comprehensively explains the API behavior: metrics returned, client-side vs server-side filtering, date range effects, default limit, and empty results. It leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining enum meanings (classification values), dimension effects, and filter behavior. It goes beyond the schema's technical descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get URL analytics report' and lists the specific metrics (citation_count, retrievals, citation_rate) and classification values. It distinguishes from sibling tools like get_domains_report and get_url_content by focusing on URL-level analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on client-side vs server-side filtering via classification and filters arrays, explains date range behavior, and mentions empty results interpretation. However, it doesn't explicitly contrast with alternative report tools like get_brands_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tracked brands for a Peec AI project. Returns brand IDs, names, and associated domains.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| limit | No | Max results (1-10000) | |
| offset | No | Results to skip |
| Name | Required | Description |
|---|---|---|
| _summary | Yes | Human-readable summary of the result |
| brands | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description only adds that it returns brand IDs, names, and domains, which does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and output without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, rich annotations, and full schema coverage, the description adequately covers what the tool does and returns. The presence of an output schema further reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description does not add additional parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (tracked brands for a project), and what is returned (IDs, names, domains). It distinguishes from sibling tools like get_brands_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool vs alternatives like get_brands_report. However, the input schema hints at using list_projects for project IDs, providing some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List AI chat interactions tracked by Peec AI. Returns up to limit results (default: 100). Recommended: use date filters to scope results. Returns chat IDs, prompt/model refs, and dates. Without date filters, returns all chats.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| start_date | No | Start date filter (YYYY-MM-DD). Omit for no lower bound. | |
| end_date | No | End date filter (YYYY-MM-DD). Omit for no upper bound. | |
| brand_id | No | Filter by brand ID. Use list_brands to find IDs. | |
| prompt_id | No | Filter by prompt ID. Use list_prompts to find IDs. | |
| model_id | No | Filter by model ID. Use list_models to find IDs. | |
| model_channel_id | No | Filter by model channel ID (e.g. openai-0, perplexity-0). Use list_model_channels to find IDs. | |
| limit | No | Max results (1-10000, default: 100) | |
| offset | No | Results to skip |
| Name | Required | Description |
|---|---|---|
| _summary | Yes | Human-readable summary of the result |
| chats | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true. The description adds useful context: default limit of 100, recommendation to use date filters, and that it returns all chats without filters. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the main purpose, then key behavior (limit, date filters recommendation, return fields). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with 9 optional parameters and an output schema, the description covers the essential behavior: what it returns, default limit, and filtering recommendation. Could mention offset/pagination, but output schema likely addresses that. Relatively complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds no additional parameter-level meaning beyond mentioning 'date filters' generically. Baseline score of 3 is appropriate since schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists AI chat interactions, mentions returned fields (chat IDs, prompt/model refs, dates), and distinguishes itself from siblings like get_chat_content which retrieves individual chat content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Recommends using date filters to scope results and warns that without filters it returns all chats, providing practical guidance. However, it does not explicitly state when not to use this tool or identify alternative tools for specific needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List model channels tracked by Peec AI. A model channel (e.g. openai-0, perplexity-0) is a stable identifier that groups one or more underlying models, so the channel ID remains constant even when the underlying model is rotated. Returns channel IDs, descriptions, the currently active model, and active status.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| limit | No | Max results (1-10000) | |
| offset | No | Results to skip |
| Name | Required | Description |
|---|---|---|
| _summary | Yes | Human-readable summary of the result |
| model_channels | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds behavioral context beyond annotations by explaining channel stability and model rotation, which is valuable for understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, clear and well-structured. Every sentence adds value: purpose, concept explanation, and return content. No fat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with excellent schema (100% coverage), output schema present, and complete annotations, the description is sufficient. It explains the key concept of model channels, which is essential for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add parameter details, but the schema already fully documents project_id, limit, offset. No additional parameter semantics needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'List model channels tracked by Peec AI' and clarifies what a model channel is (stable identifier grouping models) and what is returned (IDs, descriptions, active model, status). This distinguishes it from siblings like list_models or list_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains the concept of model channels but does not provide explicit guidance on when to use this tool versus alternatives (e.g., list_models). Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List AI models tracked by Peec AI (ChatGPT, Perplexity, etc.). Returns model IDs and active status.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| limit | No | Max results (1-10000) | |
| offset | No | Results to skip |
| Name | Required | Description |
|---|---|---|
| _summary | Yes | Human-readable summary of the result |
| models | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which are sufficient. The description adds that it returns model IDs and active status, which is useful but not critical beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the essential information without any fluff or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations, a full input schema with descriptions, and an output schema, the description adequately covers the tool's behavior. It mentions return values (IDs and status), which is sufficient for a read-only list operation. Minor gap: no explicit mention of pagination, but that's covered by parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, setting a baseline of 3. The description does not add new parameter semantics beyond what the schema provides, except for the project_id parameter referencing list_projects, which is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists AI models tracked by Peec AI, with specific examples like ChatGPT and Perplexity. The verb 'list' and resource 'models' are unambiguous, and the tool is distinct from siblings such as list_projects or list_chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like list_projects. It implicitly references the need to call list_projects to find project IDs, but lacks explicit guidance on when not to use this tool or what distinguishes it from other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Peec AI projects for the company. Returns project IDs, names, and statuses. Status values: CUSTOMER (active, ongoing monitoring), CUSTOMER_ENDED, PITCH (active demo), PITCH_ENDED (completed demo), TRIAL, TRIAL_ENDED, ONBOARDING, DELETED. Use CUSTOMER projects for current data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (1-10000) | |
| offset | No | Number of results to skip |
| Name | Required | Description |
|---|---|---|
| _summary | Yes | Human-readable summary of the result |
| projects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds value by detailing return fields (IDs, names, statuses) and enumerating status values, providing context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: first states purpose, second lists return, third explains statuses. No unnecessary words; information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of a list tool, complete schema, annotations, and output schema, the description covers all necessary context: what is returned, status meanings, and usage hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (limit, offset) are fully described in the schema with 100% coverage. The description does not add additional parameter information; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists Peec AI projects, specifying the resource and verb. It distinguishes from sibling tools like list_brands, list_chats, etc., which list different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using CUSTOMER status for current data, but lacks explicit guidance on when not to use or alternatives. No sibling tools serve the same purpose, so minimal guidance is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List search prompts for a Peec AI project. Returns prompt IDs, messages, tags, topics, locations, and search volume.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| topic_id | No | Filter by topic ID | |
| tag_id | No | Filter by tag ID | |
| limit | No | Max results (1-10000) | |
| offset | No | Results to skip |
| Name | Required | Description |
|---|---|---|
| _summary | Yes | Human-readable summary of the result |
| prompts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the list of returned fields, which is useful but not essential beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and annotations covering safety, the description is adequate but lacks details on pagination, ordering, and filtering behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists search prompts for a Peec AI project and specifies the returned fields. It distinguishes from siblings like list_projects and list_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The only contextual hint (about project_id) is in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List suggested prompts for a Peec AI project. Suggestions can be accepted to create prompts or rejected to dismiss them.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| topic_id | No | Filter by topic ID | |
| limit | No | Max results (1-10000) | |
| offset | No | Results to skip |
| Name | Required | Description |
|---|---|---|
| _summary | Yes | Human-readable summary of the result |
| prompt_suggestions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds lifecycle context (suggestions can be accepted/rejected) but does not detail pagination, ordering, or other behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the core action and resource. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, an output schema exists (so return values are covered), and description explains purpose and lifecycle. It is complete enough for an AI agent to decide and invoke, though mentioning result ordering would be a minor improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so parameters are already documented. The description adds only that suggestions are 'for a Peec AI project', which is already implied by the project_id parameter description. No additional semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List suggested prompts for a Peec AI project', using a specific verb ('list') and resource ('prompt suggestions'). It distinguishes from sibling tools like 'list_prompts' (actual prompts) and 'list_topic_suggestions' (topic-level suggestions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to view suggestions for a project, but it does not explicitly state when not to use this tool versus alternatives (e.g., 'list_prompts' for already created prompts). No usage exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List category tags for a Peec AI project. Returns tag IDs and names.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| limit | No | Max results (1-10000) | |
| offset | No | Results to skip |
| Name | Required | Description |
|---|---|---|
| _summary | Yes | Human-readable summary of the result |
| tags | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, destructive, and idempotent hints. Description adds that it returns tag IDs and names, providing minimal extra behavioral context beyond the existing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficient and front-loaded. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with complete schema annotations and output schema, the description sufficiently covers the purpose and return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add additional meaning to parameters; they are well-documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists category tags for a Peec AI project, specifying verb and resource. It distinguishes from siblings like list_brands, list_chats, and list_projects by focusing on tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description only states what it does without context for selection, though the schema cross-references list_projects for project_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List topic groupings for a Peec AI project. Returns topic IDs and names.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| limit | No | Max results (1-10000) | |
| offset | No | Results to skip |
| Name | Required | Description |
|---|---|---|
| _summary | Yes | Human-readable summary of the result |
| topics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description does not need to repeat safety. It adds value by noting the return values, but does not disclose pagination behavior or other traits beyond what is in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first sentence states purpose, second adds return information. No redundant or unnecessary text. Front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (list with pagination), schema coverage is full, annotations cover safety, and an output schema exists. The description provides the core purpose and return values, which is adequate for an agent to use correctly. Missing explicit mention of pagination is compensated by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the schema already documents all parameters. The description adds no additional meaning beyond the schema; baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'topic groupings for a Peec AI project', and specifies the return value (IDs and names). This sufficiently distinguishes it from sibling list tools like list_projects or list_topic_suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for listing topic groupings, but provides no explicit guidance on when to use this tool versus alternatives like list_topic_suggestions. No exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List suggested topics for a Peec AI project. Suggestions can be accepted to create topics or rejected to dismiss them.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| limit | No | Max results (1-10000) | |
| offset | No | Results to skip |
| Name | Required | Description |
|---|---|---|
| _summary | Yes | Human-readable summary of the result |
| topic_suggestions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, idempotent behavior. The description adds context that suggestions are actionable (can be accepted/rejected), which clarifies the tool's role in a workflow without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and additional context. No redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations and a provided output schema, the description adds appropriate context about the suggestion lifecycle. No obvious gaps for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents parameters (project_id, limit, offset). The description adds no extra parameter details, achieving only baseline value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'topic suggestions for a Peec AI project', and differentiates from sibling tools like list_topics and list_prompt_suggestions by specifying the suggestion lifecycle (accept/reject).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for displaying pending suggestions but does not explicitly state when to use this over alternatives like list_topics or list_prompt_suggestions. The schema note on project_id referencing list_projects provides minor guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get search queries that AI models generated when answering prompts. Returns the actual search queries models used to find information. Useful for understanding how AI models research topics. Without date filters, returns data across all available dates. Empty results may indicate the project has no query data for the given time range or filters.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| start_date | No | Start date (YYYY-MM-DD). Omit for no lower bound. | |
| end_date | No | End date (YYYY-MM-DD). Omit for no upper bound. | |
| filters | No | Server-side filters. Multiple filters are AND'd together. | |
| limit | No | Max results (1-10000, default: 100) | |
| offset | No | Results to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent. Description adds valuable context about date range behavior and empty results meaning, enhancing understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences that efficiently convey purpose, scope, and edge case. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, but the description does not specify the return structure (e.g., fields of each query). Although it mentions 'returns the actual search queries', it lacks details on the format, which is a gap for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds no additional parameter details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get' and the resource 'search queries that AI models generated when answering prompts'. Distinguishes from sibling 'shopping_queries' by specifying search queries for AI models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use it ('understanding how AI models research topics') and explains behavior without date filters. However, it does not explicitly mention when not to use or contrast with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get shopping/product queries that AI models generated when answering prompts. Returns product-related queries with associated product names. Useful for understanding product recommendations by AI models. Without date filters, returns data across all available dates. Empty results may indicate the project has no query data for the given time range or filters.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Project ID (uses PEECAI_PROJECT_ID env if omitted). Call list_projects to find IDs. | |
| start_date | No | Start date (YYYY-MM-DD). Omit for no lower bound. | |
| end_date | No | End date (YYYY-MM-DD). Omit for no upper bound. | |
| filters | No | Server-side filters. Multiple filters are AND'd together. | |
| limit | No | Max results (1-10000, default: 100) | |
| offset | No | Results to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about product recommendations and date range behavior, but does not significantly expand beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences covering purpose, context, and edge cases. Could be slightly more concise, but front-loaded and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description clarifies return type (product-related queries with product names) and handles empty results. Sufficient for a read-only query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds marginal parameter detail beyond the schema. The mention of date filters in the description is useful but already covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves shopping/product queries generated by AI models, with a specific verb ('Get') and resource ('shopping/product queries'). It distinguishes from siblings like 'search_queries' by focusing on product-related queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains default behavior (no date filters returns all dates) and handles empty results, but does not explicitly exclude use cases or name alternative tools for non-shopping queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0get_brands_reportget_chat_contentget_domains_reportget_url_contentget_urls_reportlist_brandslist_chatslist_model_channelslist_modelslist_projectslist_prompt_suggestionslist_promptslist_tagslist_topic_suggestionslist_topicssearch_queriesshopping_queriesEach tool has a clearly distinct purpose: listing entities (brands, chats, models, etc.) vs. retrieving reports (brands, domains, URLs) vs. fetching content. No overlapping functionality, and descriptions clarify any potential confusion.
The majority follow a consistent verb_noun pattern (list_*, get_*). The only deviation is 'shopping_queries' which uses noun_noun, but it still clearly indicates its purpose. Overall pattern is predictable.
17 tools is appropriate for an AI analytics platform covering listing, reporting, and query retrieval. Each tool serves a specific need without redundancy, fitting well within the 3-15 range plus a few extras.
The tool set covers all essential operations for the domain: listing all tracked entities, retrieving detailed reports and content, and searching queries. There are no obvious missing features for a read-only analytics monitoring server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-visibility monitoring for your brand across ChatGPT, Claude, Perplexity & Gemini.
Track brand visibility across ChatGPT, Claude, Gemini & Perplexity. Scores, competitors, trends.
AI visibility analytics for brands across citations, prompts, competitors, research, and reports.
Audit your brand's visibility across ChatGPT, Gemini, Claude, Perplexity + 6 more engines.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/thein-art/mcp-server-peecai'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
