Pirsch Analytics MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
Disambiguation5/5
Each tool targets a distinct analytics dataset: overview, totals, visitors time series, pages, entry/exit pages, referrers, goals, events, sessions, UTM, active visitors, and comparison. There is no overlap in functionality; descriptions clearly differentiate them.
Naming Consistency5/5
All tools follow the consistent pattern 'pirsch_<noun>', using snake_case. Single-word nouns (overview, total, visitors) and compound nouns (list_domains, entry_pages) are uniformly descriptive. No mixing of verb styles or naming conventions.
Tool Count4/5
With 17 tools, the count is slightly above the typical optimal range (3-15), but each tool serves a specific analytics endpoint. The set is well-scoped for a comprehensive analytics API without unnecessary duplication.
Completeness4/5
The tool set covers core analytics needs: domain listing, overview, detailed stats for pages, referrers, goals, events, sessions, UTM, active visitors, and comparisons. Missing write operations (create/update/delete) are acceptable for a read-only analytics server. Minor potential gaps exist for filters or exports.
Average 2.9/5 across 16 of 17 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It does not mention any traits like required authentication, rate limits, side effects, or whether the tool is read-only. The return format is also not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), but it lacks structure. It is concise but too vague to be useful; it does not convey essential information about the tool's purpose or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (46 parameters, no output schema, many siblings), the description is severely incomplete. It fails to provide minimally adequate context for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%, yet the description adds no information about parameters. It does not explain which filters or options are relevant for goals, leaving the agent to guess from 46 mostly undocumented parameters.
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?
The description 'Get conversion goals and their performance stats' clearly indicates the tool retrieves conversion goal data with performance metrics. However, it does not distinguish this from sibling tools like pirsch_events or pirsch_pages, which also return performance stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as pirsch_events or pirsch_overview. The description lacks context for selecting the appropriate tool among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose behavioral traits such as whether the tool requires authentication, how it handles large datasets, or if it returns paginated results. The phrase 'with sorting and search' hints at functionality but lacks detail.
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?
The description is a single sentence, highly concise. It front-loads the core purpose. However, it is too minimal for a complex tool with 46 parameters, sacrificing clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (46 parameters, no output schema, no annotations), the description is insufficient. It does not explain what 'stats' means, how to interpret results, or which filters are essential. The agent lacks critical context for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 22%, so the description should compensate. However, it only mentions 'sorting and search' generically, adding no meaning beyond what is in the schema. It does not explain which parameters map to sorting/search or how they work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get exit page stats with sorting and search', which identifies the resource (exit pages) and action (get stats). However, 'stats' is vague and does not distinguish well from sibling tools like pirsch_entry_pages or pirsch_pages. More specificity about what stats (e.g., counts, metrics) would improve clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., pirsch_pages, pirsch_entry_pages). The description does not mention prerequisites, typical use cases, or situations where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It only says 'get growth rates' without detailing return format, authentication, rate limits, or non-destructive nature. Thus, minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 9 words, which is concise but inadequate for a tool with 46 parameters and no other documentation. It is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (46 parameters, no annotations, no output schema, many siblings), the description is severely incomplete. It does not specify needed parameters, metric details, or calculation methods.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is very low (22%) with 46 parameters, yet the description adds no parameter information. It fails to compensate for the schema's gaps, leaving the agent to guess parameter meanings.
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?
The description clearly states it retrieves growth rates across core metrics for a selected period, using a specific verb and resource. It distinguishes from sibling tools like pirsch_overview or pirsch_visitors, though 'core metrics' could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as pirsch_overview or pirsch_compare. The description does not indicate scenarios where growth rates are needed or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the output without mentioning read-only nature, side effects, rate limits, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure; it omits essential context that could be front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is vastly insufficient for a tool with 46 parameters, no output schema, and no annotations. It fails to provide adequate context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 22% schema coverage, the description should compensate but adds no parameter details. It only names output fields, not how parameters affect results.
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?
The description states the tool gets event statistics and lists what it returns (counts, visitors, conversion rate, metadata keys). This is specific and distinguishes it from sibling tools that focus on other analytics (e.g., pages, visitors).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like pirsch_goals or pirsch_event_pages. The description does not mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal behavioral traits. It only mentions sorting/search/avg time but omits that it's a read operation, any default behavior, pagination, or what happens with empty results. The large schema suggests extensive filtering capability, but that is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is front-loaded with 'Get page stats'. However, given the tool's complexity (46 parameters), it is overly terse and sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 46 parameters, no output schema, no annotations, and many sibling tools. The description provides almost no context: what the output looks like, default sorting/filtering, how to combine parameters, or which sibling to use when. This is completely inadequate for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%, meaning most of the 46 parameters lack schema descriptions. The description adds only minimal semantics for sorting, search, and include_avg_time_on_page, leaving the vast majority of parameters unexplained. This forces the agent to guess or rely on parameter names.
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?
The description clearly states 'Get page stats' with specific features (sorting, search, optional avg time). However, among sibling tools like pirsch_entry_pages and pirsch_exit_pages, it does not differentiate this general page stats tool from those specific ones, causing slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as pirsch_entry_pages, pirsch_overview, or pirsch_referrers. No mention of prerequisites, filtering logic, or expected use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies a read operation but does not disclose pagination, authentication needs, rate limits, or any behavioral traits. The massive parameter list and nested object are not addressed.
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?
Single sentence, concise and front-loaded. However, it could benefit from additional structure given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 46 parameters, no output schema, and no annotations, the description is severely lacking. It omits critical details about output, filtering, and the extensive parameter set, leaving the agent with insufficient guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%. The description adds no parameter-level meaning beyond listing a few capabilities; most of the 46 parameters remain undocumented.
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?
The description clearly states it retrieves entry page stats with sorting, search, and optional average time on page. It uses a specific verb and resource, but does not differentiate from sibling tools like pirsch_pages or pirsch_exit_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings. The description lists capabilities but offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only notes the requirement for filter.event. It does not disclose read-only nature, rate limits, pagination, or output format, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it omits essential information to the point of under-specification. It is not well-structured for an agent to use effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 46 parameters, no output schema, and many sibling tools, the description is severely incomplete. It lacks parameter guidance, behavioral details, and usage context, making it inadequate for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at only 22%, the description adds no meaning beyond 'Requires filter.event', failing to explain the event parameter or any other of the 46 parameters.
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 clearly states 'Get pages on which a specific event fired' with a specific verb and resource, and distinguishes from siblings like pirsch_events or pirsch_pages by focusing on event-triggered pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Requires filter.event' as a prerequisite, but does not provide guidance on when to use this tool versus alternatives like pirsch_events or pirsch_pages, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose side effects, authentication needs, rate limits, or other behavioral traits. It only states the return content.
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?
Single sentence with no fluff, conveys the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 46 parameters, no output schema, and no annotations, the description is severely incomplete. It omits critical context on parameter usage, filtering, and pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%, and the description adds no parameter-specific meaning. It hints at output fields but does not explain how parameters like filters, date ranges, or sorting affect results.
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?
The description clearly states the tool retrieves a session list and specifies included fields (entry/exit pages, duration, device, traffic source). It is specific but does not explicitly differentiate from siblings like pirsch_session_details or pirsch_visitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description implies session analytics but does not provide context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions 'true period totals' but does not explain whether the tool is read-only, requires authentication, or has any side effects. It does not describe the output format or pagination. With no annotations, more transparency is needed, but the description is too brief.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence long, which is concise but not structured. It front-loads the purpose but omits necessary details for proper usage. Given the complexity (8 parameters, some with enums), the description is too short to be effective. While not verbose, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no annotations, and no output schema, making it complex. The description fails to explain how to specify periods, what 'true period totals' means, or how to interpret the comparison results. It is completely inadequate for an AI agent to correctly select and invoke this tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13% (only the 'compare' parameter has a description). The description does not explain the meaning of parameters like 'from', 'to', 'compare_from', 'compare_to', 'scale', 'period', or 'domain_id'. Despite the low coverage, the description adds no semantic value beyond 'compare between two periods'. Users would need to infer parameter usage.
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 clearly states the tool's purpose: compare totals and visitor series between two periods using true period totals. It uses a specific verb ('compare') and identifies the resource (totals and visitor series), and the context (between two periods). This distinguishes it from siblings like pirsch_total and pirsch_visitors, which focus on single periods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to compare two periods), but it does not provide any guidance on when not to use it or mention alternatives among the siblings. For example, it does not clarify how this differs from pirsch_growth, which might also involve comparisons. The description lacks explicit exclusions or context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Get referrer statistics' but omits behavioral traits like read-only nature, pagination details, rate limits, or authentication requirements. For a complex tool with 46 parameters, this is insufficient.
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?
The description is a single sentence, front-loaded with the core verb and resource. It is concise with no wasted words. However, it could include slightly more context without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (46 parameters, no output schema, many sibling tools), the description is extremely incomplete. It does not explain return values, how to use the nested 'filter' object, common use cases, or how to interpret results. This leaves the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%, meaning many parameters lack descriptions. The tool description does not add any parameter-specific information or compensate for the low coverage. It merely mentions 'filters and sorting' without explaining common parameters like 'from', 'to', 'filter', or 'sort'.
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 clearly states the verb 'Get', the resource 'referrer statistics', and mentions key features 'filters and sorting'. It distinguishes from sibling tools like pirsch_utm, pirsch_overview, etc., which focus on other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., pirsch_utm or pirsch_overview). It does not state prerequisites, use cases, or conditions that favor this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It lists the returned metrics but does not disclose whether results are cumulative, how filters affect output, or any other behavior like pagination or rate limits.
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?
Extremely concise at one sentence, but could efficiently include more context (e.g., common filters) while remaining brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 46 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain return format, parameter usage, or provide examples, making it inadequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%, meaning many parameters lack descriptions. The tool description only mentions 'with filters' and lists metrics but adds no meaning to individual parameters, failing to compensate for the low coverage.
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 clearly states it gets totals for specific metrics (visitors, views, sessions, etc.) with filters, distinguishing it from sibling tools that return breakdowns or lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this over alternatives like pirsch_overview or pirsch_visitors. The name 'total' implies aggregate use, but there is no when-not or comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but omits any behavioral details such as side effects, authorization needs, or rate limits. It does not contradict annotations however.
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?
The description is a single, efficient sentence that front-loads the core purpose with no redundant words. It earns its place, though brevity sacrifices useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (47 parameters, nested objects, no output schema, no annotations), the description is severely incomplete. It fails to explain filtering options, pagination, or output format, leaving the agent with minimal guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 21%, yet the description only adds meaning to the required 'type' parameter by listing its enum values. The many other parameters (47 total) are not explained in the description.
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 clearly states the tool retrieves UTM statistics and lists the supported dimensions (source, medium, campaign, content, term). This distinguishes it from sibling tools like pirsch_pages or pirsch_referrers, which focus on different metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for UTM data, but provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'optional scale and filters' but omits details like default scale, pagination behavior, rate limits, or response format, leaving significant gaps for a tool with 46 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct (one sentence), but given the tool's complexity (46 params, no annotations), it is too minimal and does not provide enough structure or front-loading to aid understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 46 parameters, no output schema, and no annotations, the description offers almost no contextual completeness. It does not explain how the time series is structured, what the filter object entails, or common usage patterns, making it inadequate for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%, yet the description adds no parameter-level information beyond 'optional scale and filters'. It fails to clarify how scale values map, how the filter object works, or specific parameter constraints, so the agent has insufficient guidance.
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 clearly states the tool gets a visitors time series, specifying the resource (visitors) and the output format (time series), and mentions optional scale and filters, which distinguishes it from siblings like pirsch_pages or pirsch_referrers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for time series data, but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It correctly indicates a read-only listing operation but does not disclose any potential side effects, rate limits, authentication requirements, or result format. The description is minimal but truthful.
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 a single, focused sentence that conveys the entire purpose with no redundant words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description does not explain what data is returned (e.g., fields, pagination). The 'search' parameter is undocumented, leaving the agent guessing its behavior. For a tool with one parameter and no output schema, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('search') with zero description coverage. The tool description does not mention this parameter or explain its meaning (e.g., filtering by domain name). The description adds no value beyond the schema structure.
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 clearly states the action ('List'), the resource ('accessible Pirsch domains'), and the purpose ('to discover domain IDs'). It distinguishes this tool from its siblings (e.g., pirsch_visitors, pirsch_pages) by focusing solely on domain discovery, not analytics data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to obtain domain IDs for subsequent API calls, but it does not explicitly state when to use it versus alternatives or when not to use it. No guidance on prerequisites or usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that data is 'cached', which is a key behavioral trait for an agent to understand potential staleness. However, it omits other details like data freshness windows or rate limits.
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?
Two short, front-loaded sentences. The first conveys purpose, the second adds an important constraint. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description covers basic behavior. However, it fails to explain what 'overview statistics' includes, which is critical given the many sibling tools with more specific metrics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no details about the only parameter, domain_id, even though the schema has 0% description coverage. The agent must rely entirely on the parameter name for meaning.
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?
The description clearly states the tool retrieves 'overview statistics for a domain', using specific verb and resource. However, it does not explicitly distinguish from siblings like pirsch_total or pirsch_visitors, leaving the agent to infer that 'overview' is a composite summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that 'filters do not apply', implying this endpoint is for unfiltered overviews. It offers no explicit guidance on when to use this tool over alternatives, nor does it list alternative tools for filtered queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the time window and what is retrieved (active visitors and pages), but it does not disclose potential rate limits, authentication requirements, or whether the data is approximate or exact. This is adequate but lacks extra behavioral context.
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 a single, efficient sentence that front-loads the key action and resource. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters (none required), no output schema, and no annotations, the description covers the basic purpose and time window. However, it lacks details on the meaning of 'active', the exact output format, and any pagination or limits. This is adequate but not fully complete for an agent to invoke without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It specifies a default of 600 seconds for the time window, implying the 'start' parameter is a number of seconds, but it does not clarify if 'start' is a timestamp or offset. The 'domain_id' parameter is not explained. The description adds some meaning but leaves ambiguity for both parameters.
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 clearly states the verb 'Get' and the resource 'active visitors and pages', with a specific time context 'past N seconds (default 600)'. This distinguishes it from sibling tools like pirsch_visitors and pirsch_pages, which likely return all data rather than active data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies real-time usage by mentioning 'past N seconds' and a default value, but it does not explicitly state when to use this tool versus alternatives like pirsch_visitors or pirsch_pages. No exclusion criteria 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. 'Get' implies read-only, but no details on permissions, rate limits, error handling, or data freshness. Adequate but not rich.
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?
Two sentences, front-loaded with the action, no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks crucial context: no output schema, no pagination info, no description of return fields (e.g., what 'page views and events' looks like). Given the complexity (46 params, many siblings), the description is too minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 46 parameters with only 22% described. The description adds meaning only for the two required nested parameters (visitor_id, session_id). No value added for the remaining 44 parameters, which is insufficient given low schema coverage.
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 clearly states the verb ('Get'), the resource ('chronological page views and events'), and the scope ('for a single session'). It distinguishes from sibling tools like 'pirsch_sessions' which lists sessions, not details of one session.
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?
The description explicitly requires 'filter.visitor_id and filter.session_id', providing a clear prerequisite. However, it does not compare to alternatives or explain when to use this tool over other session or page tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-pirsch MCP server](https://glama.ai/mcp/servers/verygoodplugins/mcp-pirsch/badges/card.svg)](https://glama.ai/mcp/servers/verygoodplugins/mcp-pirsch)

Score Badge

Copy to your README.md:

[![mcp-pirsch MCP server](https://glama.ai/mcp/servers/verygoodplugins/mcp-pirsch/badges/score.svg)](https://glama.ai/mcp/servers/verygoodplugins/mcp-pirsch)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/verygoodplugins/mcp-pirsch'

If you have feedback or need assistance with the MCP directory API, please join our Discord server