Insight Digger MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes aligned with a clear 7-step workflow, but there is some overlap between create_configuration and generate_config that could cause confusion. Both tools generate dashboard configurations, with create_configuration being described as a 'granular step' and generate_config as generating 'markdown configuration', making their boundaries unclear. Other tools like analyze_charts, analyze_source_structure, and list_sources are well-differentiated.
Naming Consistency3/5
The naming follows a mostly consistent verb_noun pattern (e.g., analyze_charts, list_sources, generate_strategy), but there are inconsistencies like setup_authentication (verb_noun) vs. validate_settings (verb_noun, but 'settings' is plural and less specific) and create_configuration vs. generate_config (different verbs for similar actions). While readable, these deviations reduce overall consistency.
Tool Count5/5
With 10 tools, the count is well-scoped for the server's purpose of transforming business questions into dashboards and insights. Each tool corresponds to a step in the described 7-step workflow, such as authentication, source discovery, and insight generation, ensuring that every tool earns its place without being excessive or insufficient.
Completeness5/5
The tool set provides complete coverage for the data analysis workflow, from authentication (setup_authentication) to insight generation (analyze_charts). It includes all necessary steps like source listing, structure analysis, strategy planning, configuration, dashboard creation, and data fetching, with no obvious gaps. The tools support the full lifecycle, enabling agents to execute end-to-end analyses without dead ends.
Average 4.1/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this tool enables subsequent analysis tools and requires API URL and JWT token, which is useful context. However, it lacks details on error handling, token expiration, security implications, or what happens on repeated calls. For an authentication setup tool with zero annotation coverage, more behavioral disclosure would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long and poorly structured for a simple authentication tool. Most content describes the broader system capabilities and workflow rather than focusing on the specific tool. The first two sentences contain the essential information, while the remaining sections (About This System, When to Use This System, Capabilities, Workflow) are unnecessary verbosity that doesn't help the agent use this specific 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?
For a 2-parameter authentication tool with no annotations and no output schema, the description provides adequate context about its prerequisite role and parameters. However, it lacks information about what the tool returns (success/failure indicators, session tokens, error messages) and doesn't address important authentication concerns like token refresh or security best practices. The completeness is minimal but sufficient for basic usage.
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%, providing clear documentation for both parameters (apiUrl and jwtToken). The description mentions these parameters but doesn't add significant meaning beyond what the schema already states. It doesn't explain parameter relationships, validation rules, or provide examples beyond the schema's URL example. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Setup authentication credentials for Sandsiv+ Insight Digger.' It specifies the exact action (setup) and resource (authentication credentials) with platform context. It distinguishes itself from siblings by being the mandatory first step before any analysis tools become available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'This must be called FIRST before any analysis tools become available.' It clearly indicates when to use this tool (as the initial authentication step) and implicitly when not to use it (after authentication is already established or for non-Sandsiv+ related tasks). The 'When to Use This System' section further contextualizes the broader platform usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses authentication requirements ('🔒 [Requires Authentication]'), caching behavior ('🔄 Auto-Cached'), workflow dependencies (data from other tools), and post-call requirements (synthesizing insights into a report). It doesn't mention rate limits, error conditions, or performance characteristics, but provides substantial behavioral context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with purpose and key constraints, but includes extensive post-call instructions (4 bullet points on report synthesis) that belong in workflow documentation rather than tool description. While some context is useful, the report formatting requirements are overly prescriptive and verbose for a tool description.
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 2-parameter tool with no annotations and no output schema, the description provides good authentication and workflow context but lacks details on return values (only mentions 'detailed insights' without format), error handling, and the 'apiUrl'/'jwtToken' mentioned in caching note (not in schema). The post-call report instructions partially compensate but don't fully address output expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'chartData' is 'automatically provided from get_charts_data step' and 'question' is 'from the workflow', clarifying their sources and typical non-requirement for manual provision. However, it doesn't detail the structure of 'chartData' (an object with additionalProperties) or format expectations for 'question', leaving some semantic gaps.
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 'analyzes data from all charts and returns detailed insights' with a specific verb ('analyzes') and resource ('data from all charts'), distinguishing it from siblings like 'get_charts_data' (data retrieval) or 'create_dashboard' (visualization creation). However, it doesn't explicitly differentiate from 'analyze_source_structure' which might have overlapping analytical functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states this is 'the final analytical step' (positioning in workflow), mentions prerequisites ('⚠️ Please authenticate first'), specifies when parameters are typically not needed ('You typically don't need to provide any parameters'), and references sibling tools for required data ('chartData' from 'get_charts_data', authentication from 'setup_authentication').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses authentication requirements ('🔒 **[Requires Authentication]**'), caching behavior ('🔄 Auto-Cached'), and that it returns a 'dict (markdown configuration).' It doesn't mention rate limits, error handling, or side effects, but covers key behavioral aspects for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with key information (authentication, purpose) but includes some redundancy (e.g., repeating authentication instructions) and could be more streamlined. Sentences like 'Returns: dict (markdown configuration).' are brief, but overall it's moderately efficient with room for improvement in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters, nested objects, no output schema, no annotations), the description is fairly complete: it covers purpose, prerequisites (authentication), parameter context, and return type. It lacks details on error cases or exact output structure, but for a tool with no annotations or output schema, it provides sufficient context for basic 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 0%, so the description must compensate. It explains that 'sourceStructure' is 'automatically provided from analyze_source_structure step' and that 'Only provide the 'question' parameter from the user,' adding context about parameter origins and usage. However, it doesn't detail the structure or format of 'sourceStructure' or what 'question' should contain, leaving gaps in parameter understanding.
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: 'Generate dashboard config (markdown) from question and source structure.' It specifies the verb ('generate'), resource ('dashboard config'), and output format ('markdown'), though it doesn't explicitly differentiate from siblings like 'create_configuration' or 'create_dashboard'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states '⚠️ **Please authenticate first** by calling the `setup_authentication` tool above' and mentions that 'sourceStructure' is auto-cached from 'analyze_source_structure' step, while 'apiUrl' and 'jwtToken' come from authentication. It also specifies 'Only provide the 'question' parameter from the user,' clarifying what inputs are needed versus automated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses key behavioral traits: authentication requirement ('Requires Authentication'), auto-caching of parameters ('🔄 Auto-Cached'), and that it's a read operation (implied by 'fetches and analyzes'). However, it lacks details on rate limits, error handling, or specific output format, which could enhance transparency.
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 appropriately sized and front-loaded, starting with key info (authentication, purpose) and using emojis for emphasis. However, some redundancy exists (e.g., repeating authentication instructions), and it could be more streamlined without losing essential details.
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 complexity (analysis operation), lack of annotations, and no output schema, the description is somewhat complete but has gaps. It covers authentication, usage context, and parameter guidance but lacks details on return values (e.g., what 'detailed column analysis' includes) and potential side effects, which would improve completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 1 parameter, the description compensates well by explaining that 'sourceId' is 'from the previous list_sources step' and that only this parameter should be provided. This adds meaningful context beyond the schema, though it could specify the format or constraints of 'sourceId' for full clarity.
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 'fetches and analyzes the structure of a given data source' and mentions it 'returns detailed column analysis,' which specifies the verb (fetch and analyze) and resource (data source structure). It distinguishes from siblings like 'list_sources' by focusing on analysis rather than listing, though it could be more explicit about how it differs from tools like 'analyze_charts' or 'generate_config.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'after selecting a source' and 'Please authenticate first by calling the `setup_authentication` tool above.' It also mentions an alternative ('list_sources' for selecting a source) and prerequisites, providing clear guidance on context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively adds context: it discloses authentication requirements ('Requires Authentication'), caching behavior ('Auto-Cached'), and workflow dependencies. It doesn't cover all potential behavioral traits (e.g., error handling or rate limits), but it provides significant operational context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but not optimally structured. It uses emojis and formatting (e.g., '🔒', '⚠️') for emphasis, which adds visual clutter. The information is front-loaded with key points, but the sentences could be more streamlined; for example, the authentication warning is repeated in different forms. It earns its place but lacks polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 required parameters, nested objects, no output schema, and no annotations), the description is fairly complete. It covers purpose, usage, dependencies, and behavioral aspects like authentication and caching. However, it doesn't explain the return values or potential errors, which would enhance completeness for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'markdownConfig' is from 'create_configuration' and 'sourceStructure' from 'analyze_source_structure,' and notes that parameters are typically auto-cached and not manually provided. This clarifies the semantics and usage of the parameters, though it doesn't detail their internal structure or validation rules.
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: 'Create a dashboard from config, source structure, and API settings.' It specifies the verb ('Create') and resource ('dashboard'), and distinguishes it from siblings like 'create_configuration' by mentioning it's a 'granular step in the analysis workflow.' However, it doesn't fully differentiate from all siblings (e.g., 'generate_config' or 'generate_strategy'), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: it states 'You typically don't need to provide any parameters for this tool' due to auto-caching, names the prerequisite tool 'setup_authentication' with a warning to authenticate first, and mentions dependencies on outputs from 'create_configuration' and 'analyze_source_structure.' This clearly defines when and how to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes key traits: authentication requirement ('🔒 **[Requires Authentication]**'), auto-caching behavior ('🔄 Auto-Cached': apiUrl and jwtToken are automatically provided from your authentication session'), and return format ('Returns: {{'status': 'success'|'error', 'error': str (if status == 'error')}}'). It doesn't mention rate limits or error handling details, but covers essential 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but could be more front-loaded. It starts with authentication requirements and auto-caching details before stating the core purpose. The sentences earn their place by providing necessary context, but the structure could be improved by leading with the tool's primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (authentication-dependent validation), no annotations, and no output schema, the description does well by covering authentication prerequisites, auto-caching behavior, and return format. It doesn't explain potential error scenarios or validation criteria in depth, but provides enough context for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description adds value by explaining that 'apiUrl and jwtToken are automatically provided from your authentication session - you typically don't need to provide these parameters,' which clarifies why the schema shows no required parameters despite mentioning args. This semantic context helps the agent understand the parameter flow.
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: 'Validate API settings by testing the connection to the external data API.' It specifies the verb 'validate' and the resource 'API settings' with the specific action of testing connection. However, it doesn't explicitly differentiate from sibling tools like 'setup_authentication' or 'create_configuration' beyond mentioning the authentication prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: '⚠️ **Please authenticate first** by calling the `setup_authentication` tool above. This tool will become fully functional after authentication.' It names the prerequisite tool and specifies when this tool should be used (after authentication), which is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes key traits: authentication requirements ('🔒 [Requires Authentication]'), caching behavior ('🔄 Auto-Cached'), and workflow integration ('granular step in the analysis workflow'). It doesn't mention rate limits, error handling, or response format, but covers essential operational aspects.
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 well-structured and front-loaded with key information: authentication requirement, purpose, and caching behavior. Every sentence adds value—no wasted words. The use of emojis and formatting (bold, warnings) enhances readability without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, nested objects, no output schema, no annotations), the description does a good job covering authentication, workflow role, and parameter sourcing. However, it lacks details on what the tool returns or how errors are handled. For a creation tool with no output schema, explaining the result would improve completeness.
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 0%, so the description must compensate. It mentions the three parameters ('question', 'columnAnalysis', 'strategy') and states they're 'automatically provided from previous steps' and 'typically don't need to be provided.' This adds context about parameter sourcing but doesn't explain what each parameter represents or their expected formats, leaving significant gaps.
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: 'Create dashboard configuration from question, column analysis, and strategy.' It specifies the verb ('create') and resource ('dashboard configuration'), and distinguishes it from siblings like 'create_dashboard' by focusing on configuration rather than the dashboard itself. However, it doesn't explicitly differentiate from 'generate_config', 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'This is a granular step in the analysis workflow' and 'You typically don't need to provide any parameters for this tool.' It also specifies prerequisites: 'Please authenticate first by calling the `setup_authentication` tool above.' This clearly defines the context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 communicates several important behavioral traits: the authentication requirement (🔒 **[Requires Authentication]**), the auto-caching behavior ('🔄 Auto-Cached': 'columnAnalysis' is automatically provided from the previous analyze_source_structure step), and the functional dependency on authentication ('This tool will become fully functional after authentication'). This provides meaningful context beyond what a basic description would include.
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 appropriately sized and well-structured with clear visual markers (🔒, 🔄, ⚠️) that help scanning. Each sentence adds value: authentication requirement, purpose, workflow context, parameter guidance, and authentication reminder. While slightly repetitive on authentication, the repetition serves as emphasis rather than waste. The information is front-loaded with the most critical details first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (workflow step with dependencies), no annotations, 0% schema coverage, and no output schema, the description does an excellent job of providing necessary context. It explains the tool's place in a workflow, its dependencies, authentication requirements, and parameter handling. The main gap is the lack of information about what the generated strategy actually contains or looks like, but this is somewhat mitigated by the tool's name and purpose being clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters, the description adds significant value. It explains that 'columnAnalysis' is 'automatically provided from the previous analyze_source_structure step' and that users should 'Only provide the 'question' parameter from the user.' This clarifies the source and handling of each parameter, which is crucial information not present in the bare schema. The description effectively compensates for the lack of schema documentation.
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: 'Generate analysis strategy for a question and column analysis' with the specific verb 'generate' and resource 'analysis strategy'. It distinguishes this as 'a granular step in the analysis workflow', which helps differentiate it from sibling tools like analyze_charts or create_dashboard. However, it doesn't explicitly contrast with the most similar sibling (generate_config).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states this is 'a granular step in the analysis workflow' and specifies that 'columnAnalysis' is automatically provided from the previous analyze_source_structure step. It also gives clear authentication prerequisites: 'Please authenticate first by calling the setup_authentication tool above.' This tells the agent exactly when to use this tool and what must happen first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 effectively describes key traits: authentication requirements ('🔒 [Requires Authentication]'), caching behavior ('🔄 Auto-Cached'), parameter handling ('automatically provided'), and output behavior ('Returns a summary... The full data is cached for the next step'). This covers critical operational aspects beyond basic functionality.
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 appropriately sized and front-loaded with key information (authentication, purpose, caching). It uses formatting (bold, emojis) for emphasis, but includes some redundancy (e.g., repeating authentication instructions) and could be slightly more streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involves authentication, caching, and dependencies), no annotations, and no output schema, the description is largely complete. It covers purpose, prerequisites, behavioral traits, and parameter context. However, it lacks details on error handling, rate limits, or the exact format of the returned summary, which could be useful for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the description compensates well. It explains that 'chartConfigs' is 'automatically provided from the create_dashboard step' and that 'You typically don't need to provide any parameters,' clarifying the parameter's source and usage context. However, it doesn't detail the structure or content of 'chartConfigs' (e.g., what it contains), leaving some ambiguity.
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: 'Fetch data for multiple charts' and 'Returns a summary of fetched charts (chart names).' It specifies the verb (fetch) and resource (data for charts), but doesn't explicitly distinguish it from sibling tools like 'analyze_charts' or 'create_dashboard' beyond mentioning the caching relationship with 'create_dashboard.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states 'You typically don't need to provide any parameters for this tool' due to auto-caching, specifies prerequisites ('Please authenticate first by calling the `setup_authentication` tool'), and indicates the tool's dependency on 'create_dashboard' for 'chartConfigs.' This clearly defines when and how to use it versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses key behavioral traits: authentication requirement ('Requires Authentication'), auto-caching behavior ('🔄 Auto-Cached'), and guidance to ask users for search terms. It doesn't mention rate limits or error handling, but covers essential 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and authentication requirements, but contains some redundancy (e.g., 'Ask user to provide a search term' and 'Ask the user for a source name to search first') and could be more streamlined. The emojis and formatting help readability but add visual clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description provides good context: authentication prerequisites, parameter guidance, and detailed return format. It lacks information about error cases or rate limits, but covers the essential operational flow adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining parameter usage: 'search' for filtering sources, 'page' and 'limit' for pagination, and clarifies that 'apiUrl and jwtToken are automatically provided'. It doesn't detail default values or constraints, but adds meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('available data sources'), and distinguishes it from siblings by emphasizing it's the 'FIRST interactive step in data analysis' rather than analysis or configuration tools like 'analyze_charts' or 'create_configuration'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('typically the FIRST interactive step in data analysis') and when not to use ('Please authenticate first by calling the `setup_authentication` tool above'), with clear prerequisites and named alternatives for authentication.
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:

[![data_narrator_mcp MCP server](https://glama.ai/mcp/servers/sandsiv/data_narrator_mcp/badges/card.svg)](https://glama.ai/mcp/servers/sandsiv/data_narrator_mcp)

Score Badge

Copy to your README.md:

[![data_narrator_mcp MCP server](https://glama.ai/mcp/servers/sandsiv/data_narrator_mcp/badges/score.svg)](https://glama.ai/mcp/servers/sandsiv/data_narrator_mcp)

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/sandsiv/data_narrator_mcp'

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