MCP Analytics
Server Quality Checklist
This repository includes a README.md file.
This repository includes a LICENSE file.
Latest release: v0.1.0
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.
This repository includes a glama.json configuration file.
- This server provides 19 tools. View schema
No known security issues or vulnerabilities reported.
This server has been verified by its author.
Add related servers to improve discoverability.
Tool Scores
- 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 'update' implies mutation, it fails to clarify whether this is a partial update (PATCH) or full replacement, what permissions are required, or error conditions (e.g., invalid UUID). For a destructive-capable operation, this lack of safety context is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise at one sentence and front-loaded with the key verb. However, the high information density is undermined by the schema mismatch, making the brevity problematic rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no output schema and zero annotations, the description should disclose success indicators, error handling, and update semantics. It provides none of these. The discrepancy between described fields and actual schema parameters further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% description coverage for the single 'uuid' parameter (baseline 3), the description confusingly references four additional fields (name, description, tags, visibility) that are not present in the input schema. This mismatch suggests either missing schema properties or misleading documentation, actively confusing the agent about what inputs are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (update) and target resource (dataset metadata) with specific field examples (name, description, tags, visibility). It distinguishes from siblings like datasets_read (read-only) and datasets_upload (create new). However, it loses a point because the fields mentioned don't appear in the provided schema, creating uncertainty about actual capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 datasets_upload (which might create vs. update) or datasets_read. There are no prerequisites mentioned, such as needing to obtain the UUID from datasets_list first, nor warnings about mutation consequences.
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 'Get' implies a read-only operation, the description does not explicitly confirm safety, idempotency, side effects, rate limits, or what data structure is returned (critical given no output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is appropriately front-loaded with the verb and contains no redundant words. However, given the lack of supporting information in annotations and schema, the extreme brevity contributes to under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter, the tool lacks an output schema and parameter descriptions. The description does not explain what constitutes a 'card' in this domain, what data is returned, or how it relates to the broader reporting workflow, leaving significant gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description completely fails to compensate. It does not explain what 'processing_id' represents, its format, or how to obtain it. The phrase 'from a report' weakly implies the parameter relates to report identification but provides no actionable semantics for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('individual card data from a report'). It implicitly distinguishes from sibling tools like 'reports_view' (which likely retrieves full report metadata) by specifying 'card data' and 'for rendering,' suggesting granular visualization data rather than report overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 siblings like 'reports_view' or 'datasets_read'. It does not mention prerequisites (e.g., obtaining a processing_id from another tool) or conditions where this tool should be avoided.
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 'List' implies a read-only operation, the description omits critical details like pagination behavior, what specific metadata is returned, rate limits, or authorization requirements given the lack of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at five words, but this brevity comes at the cost of omitting necessary context given the lack of annotations and output schema. While no words are wasted, the single sentence fails to earn its full keep by not addressing behavioral or return value questions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should explain what data structure or metadata fields are returned. It mentions 'metadata' vaguely without specifying what information is included (e.g., creation date, author, size), leaving significant gaps for an agent trying to understand the tool's utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('Max results' for the limit parameter), the schema adequately documents the single parameter. The description adds no additional parameter context, but the baseline score of 3 is appropriate since the schema already provides complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear verb ('List') and resource ('analysis reports') and adds specificity with 'with metadata'. However, it fails to distinguish this tool from siblings like 'reports_search' or 'reports_view', which could confuse the agent about when to list versus search or view specific reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus the related 'reports_search', 'reports_view', or 'report_cards' tools. There are no stated prerequisites, exclusions, or workflow context to help the agent select this over alternatives.
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 description carries full burden. While 'guides' and 'interprets' hint at behavior, missing critical details: conversation statefulness, whether it can execute actions or only advise, data access scope, and any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 6 words, single sentence. No redundancy or filler. However, given zero annotations and ambiguous positioning among concrete data tools, it may be underspecified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a conversational advisor tool among concrete data tools, the description fails to clarify scope (what analysis? what results? which tool's outputs?). No output schema exists to compensate. Needs explicit statement of advisory role and relationship to sibling data tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with 'message' parameter fully described as 'Your question or request'. Description adds no parameter-specific context, but baseline is 3 when schema coverage exceeds 80%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states specific actions (guides analysis, interprets results) and identifies the resource (conversational AI). It implicitly distinguishes from siblings like datasets_read or reports_view by emphasizing the advisory/conversational nature rather than data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 concrete data tools (datasets_*, reports_*, connectors_*). Missing crucial context about whether to use this for help interpreting other tools' outputs or for general assistance.
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 hints at asynchronous behavior ('to be built'). It lacks critical disclosure: whether this creates a ticket, requires human review, incurs costs, or how the user gets notified when complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is efficiently structured and front-loaded with the core action. However, extreme brevity becomes a liability given the lack of annotations and the significant nature of requesting custom development.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool initiating what appears to be a complex workflow (custom module development), the description is inadequate. No output schema exists, and the description fails to explain expected outcomes, response format, or next steps in the process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single 'description' parameter. The description adds minimal semantic context beyond the schema, merely framing it as a request for custom work rather than enriching the parameter's expected content or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool requests a custom analysis module using specific verb (request) and resource (custom analysis module). It implies creation of something new versus using existing tools, though it could more explicitly distinguish from siblings like 'tools_run' or 'reports_view' that use existing capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus existing analysis tools, no mention of prerequisites (approvals, billing implications), and no indication of expected timeline or process for module delivery.
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 only states 'View' without clarifying safety (read-only), error conditions (e.g., invalid processing_id), return format, or that this retrieves results from an asynchronous operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence with no filler. However, it borders on underspecified given the lack of annotations and output schema—every word earns its place, but there are too few words to fully inform the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter retrieval tool with full schema coverage, the description is minimally adequate. However, given the implied workflow complexity (processing_id from tools_run suggests async job retrieval), the description should mention that this fetches results from a previously initiated report generation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 the processing_id parameter as coming 'from tools_run'. The description adds no additional semantics, syntax, or format details beyond repeating 'processing ID', warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (View) and resource (report) and distinguishes this from sibling tools like reports_list or reports_search by specifying the lookup mechanism (processing ID). However, it misses the opportunity to clarify that this retrieves async results from tools_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives (e.g., reports_list for browsing). While the parameter description hints at a workflow with tools_run, the main description lacks explicit when/when-not guidance.
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 the tool 'Gets' information implying read-only access, but fails to mention response formats, caching behavior, whether usage stats are real-time, or any rate limits. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately front-loaded with the action verb and immediately lists the resource categories. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with 100% schema coverage and no output schema, the description is minimally adequate. However, given the presence of potentially overlapping siblings (billing, tools_info), the lack of differentiation guidance and the absence of any indication of what the tool returns leaves gaps that prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter description already documents the valid topics (platform, pricing, current_usage, manual). The description reinforces these concepts by listing them in the main text ('platform info, pricing, usage stats, or documentation'), but does not add syntax details, examples, or semantic nuances beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and lists specific resources (platform info, pricing, usage stats, documentation). It implicitly distinguishes from siblings like 'billing' or 'datasets_read' by focusing on general platform metadata rather than specific operational data, though it lacks explicit contrast with the 'billing' tool which may also handle pricing information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 siblings like 'billing' (which may overlap on pricing), 'tools_info', or 'discover_tools'. There are no prerequisites, exclusions, or alternative suggestions provided.
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 description carries full burden. Mentions 'live' (real-time behavior) but omits critical behavioral details: return format, pagination, caching behavior, rate limits, authentication requirements, and error handling. For a data retrieval tool with no output schema, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 9 words with zero waste. Front-loaded with action verb 'Pull'. Appropriate length for a single-parameter tool, though the brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for the schema complexity (1 simple string parameter with 100% coverage) but incomplete given zero annotations and no output schema. Lacks description of returned data structure, error conditions, or examples of valid connector URIs beyond the schema's inline example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description reinforces the URI parameter by referencing 'connector:// URIs', aligning with the schema's example. However, it adds no semantic depth beyond the schema's description (e.g., no syntax rules, validation details, or composition guidance).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Pull' and resource 'live data from a connected source', with specific mechanism 'connector:// URIs'. Distinguishes from siblings like connectors_list (listing) and datasets_read (cached datasets) by emphasizing 'live' data and connector URIs. Slightly vague on what constitutes a 'connected source'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or comparison with alternatives. While 'live data' implies real-time use cases, there is no guidance on when to use this vs datasets_read, reports_view, or other data retrieval tools. No prerequisites or conditions mentioned.
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 description carries full burden. It discloses the return format (shareable HTML URL) but omits critical behavioral details: whether execution creates persistent resources, consumes quotas, runs asynchronously, or modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero redundancy: first defines the action, second defines the return value. Front-loaded and appropriately brief for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that wraps other analysis tools with nested complex inputs, the description is minimally adequate. It mentions the output format, but lacks operational context (error handling, report lifecycle, required tool_name format) given the lack of annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (taskList details its internal structure), so the description is not required to compensate. However, the description adds zero parameter context, so it earns the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Execute') and target ('analysis tool'), and distinguishes from metadata siblings (tools_info, tools_schema, discover_tools) by implying runtime execution vs. inspection. Lacks explicit differentiation statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on prerequisites (e.g., whether tool_name must be discovered via discover_tools first), no mention of when to use alternatives like module_request, and no exclusions or error conditions.
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 discloses the basic search capability but omits behavioral details like pagination, result limits, whether the search is case-sensitive, or what the return format contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource, zero waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 2-parameter search tool with no output schema, but gaps remain. Without annotations or return type documentation, the description should ideally hint at result structure or volume, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 100% coverage with basic descriptions, the description adds valuable semantics by clarifying that the 'query' parameter accepts tool names and keywords, and that 'job_ids' filters by job ID—mapping abstract parameters to concrete search fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb (search), resource (reports), and searchable fields (job ID, tool name, keyword). However, it does not explicitly differentiate from siblings like 'reports_list' or 'reports_view' to help the agent choose the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like 'reports_list' or 'reports_view'. There are no prerequisites, exclusions, or contextual triggers mentioned.
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?
Without annotations, the description carries the full burden. It adds valuable behavioral context ('single-use' and 'securely') but omits critical details like token expiration time, whether previous tokens are invalidated, rate limits, or what the tool returns (URL, token string, etc.).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is efficiently structured with the action ('Generate') front-loaded, contains zero redundant words, and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter) and high schema coverage, the description adequately covers the core purpose. However, it lacks explanation of the return value since no output schema exists, which is a notable gap for a download-oriented tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description does not mention the uuid parameter or provide context about where to obtain it (e.g., from datasets_list), but the schema itself fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 'single-use download token' for datasets, using specific verbs and distinguishing itself from sibling tools like datasets_read or datasets_list by emphasizing the token-generation aspect rather than direct data access or metadata retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to select this tool versus siblings (e.g., datasets_read for metadata vs. datasets_download for file access) or prerequisites (e.g., obtaining the UUID from datasets_list first).
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 of behavioral disclosure. It adds valuable context about 'fuzzy matching' not present in the schema. However, it fails to disclose pagination behavior, what fields are searched (the schema clarifies name/description/tags, but the description doesn't), or the response format/structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no waste. It front-loads the core action ('List and search'), specifies the resource ('uploaded datasets'), and ends with the distinguishing mechanism ('fuzzy matching'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 simple parameters and no output schema, the description is minimally adequate. However, given the rich sibling ecosystem (datasets_read, datasets_update), it should clarify that this returns a catalog/list of datasets (not content) to guide the agent toward the proper tool sequence. It also omits that all parameters are optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description adds the 'fuzzy matching' semantic for the search parameter, which helps understand the matching behavior. However, it does not elaborate on the interaction between search and limit parameters or provide examples of search syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List[s] and search[es] uploaded datasets' with specific mechanism 'fuzzy matching'. This distinguishes it from siblings like datasets_read (content retrieval) and datasets_upload (creation). However, it could explicitly clarify that this returns metadata/catalog entries rather than dataset contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like datasets_read (which likely requires a specific dataset ID obtained from this tool) or datasets_search (if it existed). It omits that both parameters are optional for full listing versus filtered search.
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 disclosure burden. It successfully explains the indirect mechanism (returns a token and curl command rather than performing the upload itself) and mentions security ('secure upload token'), but omits side effects, whether a dataset record is created immediately or post-upload, or token constraints beyond expiration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with zero redundancy. First sentence establishes purpose; second sentence discloses return format. Every word earns its place—'secure' implies authentication requirements, 'curl command' reveals the CLI-oriented workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description adequately covers the return value ('UUID + curl command') and the core action. It appropriately delegates parameter details to the schema. Minor gap: could clarify the relationship between token generation and actual dataset creation in the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single parameter has a complete description), establishing a baseline of 3. The description adds context that the token is for 'CSV files,' which helps frame the expiration parameter's purpose, but does not elaborate on the seconds format, valid ranges, or consequences of short/long expiration times beyond the schema's default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Generate') and resource ('secure upload token') with specific scope ('for CSV files'). The mention of returning a 'UUID + curl command' implicitly distinguishes it from sibling tools like datasets_update or datasets_read which operate on existing datasets directly rather than via upload tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this versus siblings like datasets_update (for modifying existing datasets) or datasets_read. Does not clarify prerequisites (e.g., whether a dataset must be created first) or when the token-based approach is preferred over direct ingestion.
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 of behavioral disclosure. It successfully clarifies what content is returned (use cases, assumptions, data requirements) beyond a generic 'information' label, implying this is a metadata retrieval operation. However, it lacks safety indicators (read-only status), error handling details (what if tool_name is invalid), or rate limit warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with high information density. The critical differentiator ('use cases, assumptions, data requirements') is placed at the end via em-dash for emphasis. No words are wasted; every clause earns its place by either stating the operation or clarifying the scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one required parameter (fully documented in schema) and no output schema, the description adequately compensates by specifying the categories of information returned. For a simple read-only metadata tool, this is sufficient, though it could be improved by mentioning error cases or return format (structured vs text).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single 'tool_name' parameter fully documented as 'Name of the tool'. The description mentions 'a specific analysis tool' which implicitly reinforces the parameter purpose, but adds no additional semantic value (examples, format constraints, or lookup behavior) beyond what the schema already provides. Baseline 3 is appropriate for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (get detailed information) and resource (analysis tool), and the em-dash clarification ('use cases, assumptions, data requirements') effectively distinguishes this from siblings like tools_schema (technical specs) or discover_tools (listing). However, it lacks explicit comparison to these siblings to make the differentiation foolproof.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the specific information types returned (use cases, assumptions, data requirements), suggesting when an agent should use this tool. However, it lacks explicit 'when to use vs alternatives' guidance or mention of prerequisites like needing the exact tool_name from discover_tools first.
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 fails to explain what 'portal' returns (URL vs redirect), whether 'usage' is read-only, side effects, or response formats. The agent cannot determine if 'portal' is destructive or requires special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of nine words with zero redundancy. Every word earns its place by describing a distinct capability of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool without output schema, the description adequately covers the available actions. However, it lacks information about return values (e.g., whether 'portal' returns a URL string) and doesn't clarify the difference between 'status' and 'usage' actions, leaving a small gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage (parameter described as 'Billing action'), the baseline is 3. The description adds value by mapping the enum values to specific outcomes: 'status' checks subscription, 'portal' opens billing portal, and implies 'usage' handles credit balance checking. This semantic mapping helps the agent select the correct action value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states three specific functions (checking credit balance, checking subscription status, opening billing portal) using distinct verbs. It clearly distinguishes this tool from siblings like datasets_list, reports_search, and connectors_query which handle data rather than account billing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description lists available actions, it provides no explicit guidance on when to prefer this over siblings (though the domain is distinct enough) or prerequisites like authentication requirements. It doesn't specify when to use 'status' vs 'usage' for checking balance information.
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 but fails to mention return format, pagination behavior, authentication requirements, or what determines connector availability (user permissions vs. global list). 'And more' leaves scope undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. The examples are appended without waste, making it appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While adequate for a parameter-less list operation, the description lacks mention of return structure or the relationship between connectors and datasets (relevant given sibling tools). Given no output schema exists, some indication of what the list contains would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage trivially. Per the scoring rubric, this establishes a baseline score of 4 with no penalty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('List') and resource ('data connectors'), and includes concrete examples (GA4, Google Search Console) that clarify the scope. The naming clearly distinguishes it from the sibling 'connectors_query' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies this is for discovery/ enumeration versus the sibling 'connectors_query' (which likely extracts data), it provides no explicit guidance on when to use this versus other tools like 'datasets_list' or what prerequisites exist for connectors to appear as 'available'.
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?
Without annotations, the description carries full burden. It successfully discloses the search mechanism ('semantic search') and corpus size ('50+'), but omits critical behavioral details: return format (tool IDs? names? descriptions?), result cardinality, and whether the search is fuzzy or exact. No safety or performance characteristics mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. Front-loaded with the action verb 'Find'. First sentence defines purpose and parameter mapping; second sentence discloses mechanism and scope. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While appropriate for a simple 2-parameter tool, the absence of annotations and output schema creates an information gap. The description should ideally disclose return value structure (list of tool metadata?) since no output schema exists to document this. Adequate but not fully self-describing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description reinforces the relationship between 'data/question' and the parameters, but adds no syntax guidance, format examples, or semantic constraints (e.g., whether dataset UUID is required when query is provided) beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'Find' (verb) + 'analysis tools' (resource) + 'semantic search' (mechanism) clearly distinguishes this from sibling execution tools like tools_run and static listing tools like tools_info. The scope '50+ statistical and ML tools' precisely defines the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit context via 'matching your data or question' which maps to the two parameters, but lacks explicit guidance on when to use this versus tools_info (browse all) or tools_run (direct execution). Does not clarify that both parameters are optional despite the schema showing zero required fields.
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 carries the full burden. It successfully discloses the preview nature (limited rows) and return structure (rows, columns, types), but omits safety confirmations, error handling behavior, or whether the secret parameter triggers different access permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the primary action ('Read dataset contents') and uses an em-dash to append the specific return details. No words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description compensates well by listing what is returned (rows, columns, types). It appropriately covers the tool's scope for a simple read operation, though it could mention authentication patterns or privacy implications of the secret parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds conceptual context by framing the operation as a 'preview', which explains the intent behind the 'rows' parameter, but does not elaborate on the relationship between uuid and secret or parameter syntax beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Read', 'preview') and identifies the resource ('dataset contents'). The term 'preview' effectively distinguishes this from sibling tools like datasets_download (full extraction) and datasets_list (metadata only), while 'Read' contrasts with datasets_update/write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The term 'preview' implies an exploration use case (sampling data before full download), suggesting when to use this tool. However, it lacks explicit guidance such as 'Use datasets_download for full extraction' or prerequisites like when the secret key is required.
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 provided, so description carries full burden. It adds valuable context about what the schema contains (column_mapping, module_parameters), but omits operational traits like safety (read-only), idempotency, or side effects that agents need for mutation risk assessment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently packs purpose, return type, and usage context. No redundancy or filler; information density is optimal with critical prerequisite information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a simple single-parameter tool. Covers the essential workflow integration (prerequisite for tools_run) and return value intent (JSON schema), though could clarify whether the return is a string, object, or structured format given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for the single 'tool_name' parameter. Description implies the parameter by referencing 'a tool' but adds no additional semantics, examples, or format constraints beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' with resource 'JSON schema' and distinguishes from sibling tools like 'tools_info' and 'tools_run' by specifying it retrieves structural schema data rather than general metadata or execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states temporal workflow relationship: schema must be retrieved 'before tools_run' and highlights specific schema components ('column_mapping and module_parameters') that are prerequisites, clearly indicating when to invoke this tool.
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:
Score Badge
Copy to your README.md:
How to claim the server?
If you are the author of the server, you simply need to authenticate using GitHub.
However, if the MCP server belongs to an organization, you need to first add glama.json to the root of your repository.
{
"$schema": "https://glama.ai/mcp/schemas/server.json",
"maintainers": [
"your-github-username"
]
}Then, authenticate using GitHub.
Browse examples.
How to make a release?
A "release" on Glama is not the same as a GitHub release. To create a Glama release:
- Claim the server if you haven't already.
- Go to the Dockerfile admin page, configure the build spec, and click Deploy.
- Once the build test succeeds, click Make Release, enter a version, and publish.
This process allows Glama to run security checks on your server and enables users to deploy it.
How to add a LICENSE?
Please follow the instructions in the GitHub documentation.
Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear on the server after some time, you can manually trigger a new scan using the MCP server admin interface.
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.
Latest Blog Posts
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/embeddedlayers/mcp-analytics'
If you have feedback or need assistance with the MCP directory API, please join our Discord server