Artsy Analytics MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have clear distinctions in their primary focus areas (activity, artworks, audience, inquiries, sales, time series, top content, demographics, custom queries), but there is notable overlap between some tools. For example, 'get_partner_complete_analytics' overlaps with many others by providing an overview, and 'get_partner_time_series_analytics' overlaps with specific time series tools like 'get_partner_inquiry_time_series' and 'get_partner_sales_time_series'. Descriptions help clarify, but an agent might struggle to choose between overlapping tools for specific needs.
Naming Consistency5/5
All tool names follow a consistent 'get_partner_*_stats' or 'get_partner_*_analytics' pattern, with variations like 'time_series', 'top_artworks', or 'visitor_demographics' fitting logically. The naming is highly predictable and readable, using snake_case uniformly throughout. This consistency makes it easy for an agent to understand the structure and purpose of each tool at a glance.
Tool Count4/5
With 14 tools, the count is reasonable for an analytics server covering various aspects like activity, sales, inquiries, and demographics. It's slightly on the higher side but well-scoped to provide detailed insights without being overwhelming. Each tool appears to serve a specific analytical function, though some redundancy might be present, keeping it within a manageable range for the domain.
Completeness4/5
The tool set covers a broad range of analytics for partners, including activity, audience, inquiries, sales, time series, top content, and demographics, with a custom query option for flexibility. Minor gaps exist, such as no explicit tools for updating or deleting analytics data (which might be intentional if read-only) or more granular filtering options, but the surface is comprehensive for querying and reporting purposes, allowing agents to access most needed metrics.
Average 3/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s]' data, implying a read-only operation, but lacks details on permissions, rate limits, data freshness, or what the output includes (e.g., trends, specific statistics). For a tool with no annotations, this leaves significant gaps in understanding its behavior and constraints.
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 core purpose without unnecessary words. It directly states the action and resource, making it easy to parse quickly. Every part of the sentence contributes to understanding the tool's function, with no wasted verbiage.
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 complexity of analytics tools and the lack of annotations and output schema, the description is insufficiently complete. It does not explain what 'statistics and trends' include, how data is returned, or any behavioral aspects like error handling. For a tool with no structured output and multiple similar siblings, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (partnerId and period, including enum values). The description adds no additional parameter semantics beyond what the schema provides, such as explaining what 'publishing statistics' entail or how the period affects results. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 verb 'Get' and the resource 'partner artwork publishing statistics and trends', making the purpose understandable. It distinguishes itself from siblings by focusing specifically on 'artworks published' statistics rather than other metrics like activity, audience, sales, or inquiries. However, it doesn't explicitly contrast with the most similar sibling 'get_partner_top_artworks', which might also involve artwork data.
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. With multiple sibling tools for partner analytics (e.g., get_partner_activity_stats, get_partner_sales_stats, get_partner_top_artworks), there is no indication of when 'artworks published' stats are appropriate versus other metrics, nor any mention of prerequisites or exclusions for usage.
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 only states what data is retrieved without disclosing behavioral traits like authentication requirements, rate limits, data freshness, or response format. It mentions 'analytics including' but doesn't clarify if this is exhaustive or if there are limitations.
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. It avoids unnecessary words, though it could be slightly more structured by separating key points. Every part earns its place by specifying the analytics scope.
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 no annotations and no output schema, the description is incomplete for a tool with 3 parameters. It lacks details on behavioral aspects, response format, and doesn't compensate for the missing structured data, making it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters well. The description adds no parameter-specific semantics beyond implying that 'partner audience analytics' relates to the partnerId parameter, but it doesn't explain parameter interactions or provide additional context beyond the schema.
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 verb 'Get' and the resource 'partner audience analytics' with specific metrics mentioned (unique visitors, commercial visitors, geographic data). It distinguishes from siblings by focusing on audience analytics rather than activity, sales, or other partner metrics, though it doesn't explicitly name alternatives.
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 like get_partner_visitor_demographics or query_analytics_custom. The description implies usage for audience analytics but offers no explicit when/when-not instructions or comparison with sibling tools.
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 provides minimal behavioral context. It doesn't mention authentication requirements, rate limits, response format, whether data is real-time or cached, or any limitations of the 'comprehensive' overview. The agent must infer behavior from the tool name and description alone.
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 gets straight to the point. However, it could be more front-loaded with differentiation from siblings, and the phrase 'comprehensive analytics overview' is somewhat redundant with 'all major metrics'.
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?
For a tool with no annotations, no output schema, and 12 sibling tools offering similar analytics, the description is insufficient. It doesn't explain what 'comprehensive' means, what metrics are included, how this differs from query_analytics_custom, or what format the response takes. The agent lacks crucial context for proper tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain what 'comprehensive analytics' includes or how the period parameter affects the returned metrics.
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 verb 'Get' and resource 'comprehensive analytics overview for a partner', specifying it includes 'all major metrics'. It distinguishes from siblings by implying breadth rather than specific metric categories, but doesn't explicitly name how it differs from tools like 'query_analytics_custom'.
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 the many sibling tools is provided. The description mentions 'comprehensive' and 'all major metrics', but doesn't specify when this broad overview is preferable to the more specific sibling tools like get_partner_sales_stats or get_partner_audience_stats.
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 the full burden of behavioral disclosure. While 'Get' implies a read operation, it doesn't specify authentication requirements, rate limits, data freshness, or what 'detailed' entails (e.g., granularity, format). For a tool with no annotation coverage, this leaves 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.
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. Every word earns its place, though it could be slightly more structured by separating purpose from output characteristics.
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's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks context on usage, behavioral traits, and output format. With no output schema, it should ideally hint at return values (e.g., 'returns time-series data with timestamps and metrics').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description mentions 'time series data and response times' which aligns with the parameters but doesn't add meaningful semantics beyond what the schema provides (e.g., explaining how 'cumulative' affects response times). Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose with specific verbs ('Get detailed inquiry analytics') and resources ('time series data and response times'), distinguishing it from siblings like 'get_partner_inquiries_stats' which likely provides summary statistics rather than time-series data. However, it doesn't explicitly differentiate from 'get_partner_time_series_analytics' which might be similar.
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. With multiple sibling tools like 'get_partner_inquiries_stats' and 'get_partner_time_series_analytics', the description lacks explicit context about when this specific time-series inquiry tool is appropriate versus other analytics tools.
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 the full burden of behavioral disclosure. While it mentions 'detailed pageview analytics' and 'time series support,' it fails to describe important behavioral aspects such as whether this is a read-only operation, what authentication or permissions are required, rate limits, pagination behavior, or what format the analytics data returns. For an analytics tool with no annotation coverage, this leaves significant gaps.
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 gets straight to the point without unnecessary words. It's appropriately sized for the tool's complexity, though it could potentially be more front-loaded with the most critical information about when to use this versus sibling tools.
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?
For an analytics tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'detailed pageview analytics' includes, how the modern schema differs from other schemas, what the output format looks like, or any behavioral constraints. Given the rich sibling tool ecosystem, more context is needed to help an agent choose and use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'time series support' which relates to the 'includeTimeSeries' and 'cumulative' parameters, but doesn't add meaningful semantic context beyond what's already in the schema descriptions. With 100% schema description coverage, the baseline is 3 - the schema already documents all parameters well, and the description provides only marginal additional value.
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 action ('Get detailed pageview analytics') and resource ('modern pageview schema'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from its many sibling analytics tools, particularly those like 'get_partner_time_series_analytics' or 'get_partner_audience_stats' that might also provide pageview-related data.
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 mentions 'time series support' which implies a use case for temporal analysis, but provides no explicit guidance on when to choose this tool over its 12 sibling analytics tools. There's no mention of alternatives, prerequisites, or specific scenarios where this tool is preferred versus others like 'get_partner_complete_analytics' or 'query_analytics_custom'.
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 for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify authentication requirements, rate limits, data freshness, error conditions, or what happens when invalid parameters are provided. For a tool with no annotation coverage, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the tool's purpose. Every word contributes meaning - 'partner sales analytics' specifies the domain, and the three metrics provide concrete examples of what's included. There's no wasted verbiage.
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?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the analytics data returns, whether it's aggregated or detailed, how response times are calculated, or any limitations. Given the complexity implied by the sibling tools and lack of structured documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
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 action ('Get') and resource ('partner sales analytics') with specific metrics listed (order count, revenue, response times). It distinguishes from some siblings like 'get_partner_audience_stats' by focusing on sales, but doesn't explicitly differentiate from similar tools like 'get_partner_sales_time_series' or 'get_partner_complete_analytics'.
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. With 12 sibling tools including closely related ones like 'get_partner_sales_time_series' and 'get_partner_complete_analytics', there's no indication of when this specific sales analytics tool is appropriate versus those other options.
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 for behavioral disclosure. While 'Get' implies a read operation, it doesn't address important behavioral aspects like authentication requirements, rate limits, data freshness, pagination, or error conditions. For an analytics tool with no annotation coverage, this leaves 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for the tool's complexity, though it could potentially benefit from slightly more structure given the many sibling tools in this domain.
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's moderate complexity (3 parameters, no output schema, no annotations), the description provides basic context but leaves significant gaps. It doesn't explain what format the time series data returns, what time granularity is used, whether data is real-time or historical, or how this differs from other analytics tools. For a tool with no output schema, more detail about return values would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'revenue amounts' which adds some context about the data returned, but doesn't provide additional parameter semantics beyond what's already documented in the schema (which has 100% coverage). The schema already fully describes all three parameters with their purposes, defaults, and enums, so the description adds minimal value here.
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's purpose with a specific verb ('Get') and resource ('detailed sales analytics with time series data'), making it immediately understandable. However, it doesn't explicitly differentiate this tool from its many sibling analytics tools (like 'get_partner_sales_stats' or 'get_partner_time_series_analytics'), which would require more specific scope definition to earn a 5.
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 the 12 sibling analytics tools. With multiple tools covering partner analytics, sales stats, time series, and custom queries, the agent receives no help in selecting the appropriate tool for specific analytical needs.
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 the full burden of behavioral disclosure. While it mentions 'optional cumulative view,' it doesn't describe what the tool returns (e.g., data format, time granularity), whether it requires authentication, has rate limits, or handles errors. For a data retrieval tool with zero annotation coverage, this is a significant gap in transparency.
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 core purpose ('Get time series data for partner analytics') and includes a key optional feature ('with optional cumulative view'). There's no wasted verbiage or redundancy.
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 complexity of analytics tools and the lack of both annotations and an output schema, the description is insufficient. It doesn't explain what the returned data looks like (e.g., format, structure), how to interpret it, or any prerequisites (e.g., authentication). For a tool with 4 parameters and no structured output documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all four parameters (partnerId, metric, period, cumulative) with descriptions, defaults, and enums. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 without adding value.
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 verb ('Get') and resource ('time series data for partner analytics'), making the purpose understandable. However, it doesn't differentiate this tool from its many sibling analytics tools (like get_partner_inquiry_time_series or get_partner_sales_time_series), which likely also retrieve time series data for different metrics or contexts.
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. With 13 sibling tools, many of which appear to be analytics-related (e.g., get_partner_inquiry_time_series, get_partner_sales_time_series), the lack of differentiation leaves the agent guessing about which tool to select for specific analytical needs.
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 the full burden of behavioral disclosure. It mentions ranking by views but doesn't specify whether this is a read-only operation, requires authentication, has rate limits, or what the output format looks like (e.g., list structure, pagination). For a tool with 4 parameters and no output schema, this leaves significant gaps in understanding how it behaves.
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 core purpose without unnecessary words. Every part earns its place by specifying content types and ranking metric, making it easy to scan and understand quickly.
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 complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like safety, output format, or error handling, which are crucial for an AI agent to use it correctly. Without annotations or output schema, more context is needed to compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly with descriptions, defaults, and enums. The description adds minimal value by implying the ranking is based on views, which is not explicitly stated in the schema but is somewhat redundant with the tool's name. Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb ('Get') and resource ('top-performing content'), specifying the content types (artworks, shows, artists, or viewing rooms) and ranking metric (by views). It distinguishes from siblings like get_partner_artworks_published_stats by focusing on performance ranking rather than publication or sales statistics. However, it doesn't explicitly differentiate from get_partner_top_artworks, which might be a more specific variant.
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. It doesn't mention prerequisites (e.g., needing partnerId), exclusions, or comparisons with siblings like get_partner_top_artworks or query_analytics_custom. Usage is implied by the name and parameters but not explicitly stated.
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 for behavioral disclosure. It states the action but doesn't describe important behavioral aspects like authentication requirements, rate limits, error handling, response format, or whether this is a read-only or mutation operation. The description is minimal and lacks operational 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 extremely concise - a single sentence that efficiently communicates the core functionality without any wasted words. It's appropriately sized for a tool with clear parameters documented elsewhere.
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?
For a GraphQL query execution tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the analytics schema contains, what types of queries are supported, what the response format will be, or any limitations. Given the complexity of GraphQL and the lack of structured documentation, the description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions 'GraphQL query' which is already in the parameter descriptions. Baseline 3 is appropriate when schema does the heavy lifting.
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 action ('Execute a custom GraphQL query') and target ('against the analytics schema'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools, which are all analytics-related but appear to be predefined queries rather than custom ones.
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 the many sibling analytics tools. It doesn't mention alternatives, prerequisites, or specific contexts where a custom GraphQL query would be preferred over the predefined analytics endpoints.
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 the full burden of behavioral disclosure. It states this is a 'Get' operation (implying read-only), but doesn't mention authentication requirements, rate limits, response format, or whether it returns aggregated vs. raw data. For a tool with no annotation coverage, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the tool's purpose. Every word contributes meaning without redundancy or unnecessary elaboration, making it easy to parse and understand quickly.
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?
For a read-only analytics tool with 2 parameters and no output schema, the description provides basic purpose but lacks important context. Without annotations or output schema, it should explain more about what the analytics include, how data is returned, and when to choose this over sibling tools. The description is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter information beyond what's already in the schema (which has 100% coverage). It doesn't explain what 'partner activity analytics' means in relation to the parameters, provide examples of partner IDs, or clarify the time period options. With complete schema coverage, the baseline score of 3 is appropriate.
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 verb 'Get' and the resource 'partner activity analytics', specifying the types of analytics included (pageviews, artwork views, unique visitors). It distinguishes from some siblings by focusing on general activity stats rather than specific aspects like sales or inquiries, but doesn't explicitly differentiate from all alternatives like 'get_partner_complete_analytics'.
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 the many sibling alternatives. There's no mention of prerequisites, use cases, or comparisons to similar tools like 'get_partner_complete_analytics' or 'get_partner_audience_stats', leaving the agent to guess based on tool names alone.
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 the full burden of behavioral disclosure. It states the tool retrieves analytics (implying a read-only operation) but doesn't cover important aspects like authentication requirements, rate limits, data freshness, or error conditions. For a stats tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 core purpose without unnecessary words. Every element ('Get partner inquiry analytics including inquiry count and response times') serves a clear purpose, making it easy to parse while maintaining completeness for its length.
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's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers what the tool does but lacks context about when to use it, behavioral details, and output format. Without annotations or output schema, the agent must rely heavily on the description, which doesn't fully compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter information beyond what's already in the schema (which has 100% coverage). It mentions 'partner inquiry analytics' which aligns with the 'partnerId' parameter, and 'analytics' implies some time period, matching the 'period' parameter. However, it provides no additional context about parameter usage, constraints, or relationships beyond the schema's descriptions.
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 verb 'Get' and the resource 'partner inquiry analytics', specifying the metrics included (inquiry count and response times). It distinguishes this tool from siblings like 'get_partner_sales_stats' or 'get_partner_audience_stats' by focusing on inquiry analytics, though it doesn't explicitly contrast with 'get_partner_inquiry_time_series' which might offer similar data in a different format.
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. It doesn't mention sibling tools like 'get_partner_inquiry_time_series' (which might provide time-series data) or 'get_partner_complete_analytics' (which might include broader metrics), leaving the agent to infer usage context from tool names alone.
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 mentions 'most viewed artworks with ranking data', hinting at read-only behavior, but doesn't disclose critical traits like authentication needs, rate limits, pagination, or error handling. For a tool with no annotations, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's function without redundancy. It's front-loaded and appropriately sized for a straightforward retrieval tool.
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 no annotations and no output schema, the description is minimal but covers the core purpose. It lacks details on return values, error cases, or operational constraints, which are needed for full context. However, for a simple read operation with good schema coverage, it's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters like 'limit', 'partnerId', and 'period'. The description adds no additional meaning beyond implying ranking is based on views over a time period, which aligns with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb 'Get' and resource 'partner's most viewed artworks with ranking data', making the purpose evident. It distinguishes from siblings by focusing specifically on top artworks with ranking, unlike general stats or time-series tools. However, it doesn't explicitly contrast with 'get_partner_top_content', which might be a close alternative.
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 like 'get_partner_top_content' or other analytics siblings. The description implies usage for ranking data but doesn't specify prerequisites, exclusions, or comparative contexts, leaving the agent to infer based on tool names alone.
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 only states what the tool does, not how it behaves. It lacks details on permissions, rate limits, data freshness, pagination, or error handling. For a data retrieval tool with 5 parameters, this leaves 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.
Conciseness5/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 without unnecessary words. Every element (verb, resource, breakdown dimensions) earns its place, making it easy to parse quickly.
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 5 parameters, no annotations, and no output schema, the description is minimally adequate but incomplete. It covers the what but not the how or when, leaving gaps in behavioral context and usage guidance that could hinder effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal value by listing breakdown types that correspond to 'metric' and 'objectType' enums, but doesn't explain parameter interactions or semantics beyond what's in the schema.
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 verb 'Get' and the resource 'visitor demographic breakdowns', specifying the breakdown dimensions (device, country, referral source, landing page). It distinguishes from siblings by focusing on demographics rather than activity, sales, or time series, though it doesn't explicitly contrast with them.
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 like 'get_partner_audience_stats' or 'get_partner_complete_analytics'. The description implies usage for demographic data but doesn't specify prerequisites, exclusions, or comparative contexts with sibling 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-tests MCP server](https://glama.ai/mcp/servers/damassi/mcp-tests/badges/card.svg)](https://glama.ai/mcp/servers/damassi/mcp-tests)

Score Badge

Copy to your README.md:

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

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/damassi/mcp-tests'

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