mcp-data-service

by lengzhanbao

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.1
Disambiguation3/5
Most tools are distinct, but list_columns and get_schema clearly overlap, and query_video_stats, aggregate_stats, and data_insights have fuzzy boundaries around statistics and insights. Descriptions help somewhat, but an agent could easily select the wrong tool for a given analytical request.
Naming Consistency3/5
All names are snake_case, but conventions are mixed: verb-noun names like list_columns and preview_data coexist with noun-phrase names like data_insights and correlation_analysis. query_video_stats also stands out as a domain-specific exception to the otherwise general-purpose naming pattern.
Tool Count5/5
Eleven tools is an appropriate size for a data service covering source management, schema inspection, preview, aggregation, correlation, SQL querying, and health checks. The count is neither bloated nor too thin for the stated purpose.
Completeness4/5
The tool surface covers the core read-only data workflow well: discovering sources, inspecting schema, previewing, aggregating, running SQL, checking correlations, and getting automated insights. Minor gaps exist—such as no explicit dataset-comparison or export tool—but they are workable through sql_query and preview_data.
Average 3.3/5 across 11 of 11 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

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 for disclosing behavior. It only states a high-level grouping/aggregation operation; it does not explain whether the tool is read-only, what output is returned, how grouping is performed, how missing values are handled, or whether a data source is required. The behavior beyond the one-liner is completely undisclosed.
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 short and easy to read, but it is under-specified rather than appropriately concise. A single generic clause leaves out nearly all operational context and does not earn its place as the primary tool definition. There is no structure, examples, or routing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has six optional parameters and no required fields, a one-line Chinese phrase is insufficient for an agent to invoke it with confidence. Although an output schema exists, the description still omits how to choose grouping columns, which aggregation modes are valid, what data source is being aggregated, and how this tool differs from similar analysis tools. Important context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level meaning and does not mention agg, group_by, metric, condition, source, or format. Schema descriptions cover 4 of 6 parameters (67%), but format and source remain unexplained, and the description does not compensate for this gap. An agent gets little help from the description in deciding how to set parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '按字段分组聚合' conveys a core action of grouping by a field and aggregating, so it is not a pure tautology. However, it does not specify the data resource, the output, or which fields are involved, and it does not differentiate the tool from siblings like sql_query or data_insights. The purpose is clear at a high level but still vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use aggregate_stats versus sibling tools such as sql_query, correlation_analysis, or data_insights. The description does not state prerequisites, exclusions, or scenarios that favor this tool. An agent must infer usage entirely from the name and schema.
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?
There are no annotations, so the description carries the behavioral transparency burden. It does disclose a useful behavior: column names follow the actual CSV schema and metric must be an existing column, alerting the agent to dynamic data-dependent validation. However, it does not describe error behavior, read-only guarantees, or how the rule/format/page_size settings affect the response.
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 short and has no filler, but it is undersized for a tool with 8 parameters and 11 sibling tools. It is concise without being appropriately informative, and it lacks any structural organization or key usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description still omits critical context: when to use this tool instead of aggregate_stats/sql_query, how rule/page_size/format interact, and what happens when invalid column names are supplied. It is a minimal skeleton rather than a complete tool definition.
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%, and all 8 parameters already have descriptions with defaults and constraints. The description adds essentially no new parameter meaning; its 'metric must exist' caveat merely restates the schema description for metric. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says "查询统计数据" (query statistics data), which is a verb plus resource, but it is too generic and does not specify what kind of video statistics are returned or how they are computed. It does not meaningfully distinguish the tool from siblings like aggregate_stats or data_insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided, and no alternatives are named or excluded. The note about metric being an existing CSV column is a validation constraint, not a usage guideline. Given sibling tools like sql_query and aggregate_stats, an agent has no basis to decide when to choose this tool.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does add useful context with the 1.5σ deviation threshold and the warning that column names depend on the actual CSV. However, it does not state whether the operation is read-only, how failures might occur, or what the 'suggestions' are based on, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the tool's primary outputs and then adds a decisive caveat about CSV column names. There is no filler or redundancy. It could include more parameter guidance, but for what it conveys it is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return-value detail is covered elsewhere, but there are no annotations and no schema-level parameter descriptions. The description leaves the semantics of metric and source unexplained and offers no guidance on when this tool is preferable to sibling analytics tools. An agent is not equipped to select and invoke this tool correctly based solely on the given information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what metric or source mean or how they affect the output. The caveat that column names follow the actual CSV is a small hint that metric likely references CSV columns, but it is not a sufficient explanation. With two undocumented optional parameters, the agent cannot confidently construct a correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool produces automated insights composed of a data overview, anomaly drill-down based on a 1.5σ deviation threshold, and suggestions. It does not use a direct verb like 'generates' or 'returns', but the phrase '自动洞察' makes the operation clear enough. The stated combination of overview, anomaly detection, and recommendations helps distinguish this from sibling analytics tools such as aggregate_stats or query_video_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use data_insights instead of alternative tools like aggregate_stats, correlation_analysis, or sql_query. No exclusions, preconditions, or sibling comparisons are provided. An agent would have to infer when this tool is appropriate from its name and high-level output list alone.
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 behavioral burden. It does disclose pagination and conditional filtering, and 'preview' weakly implies a read-only nature. However, it omits important behavioral details such as output format, source requirements, default behavior, or whether previews are bounded or sampled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, and the main behavior is front-loaded. It is appropriately concise, though it may be slightly too terse given the number of parameters and lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters, no annotations, 0% parameter documentation, and no guidance on source selection or condition syntax. The description is not complete enough for an agent to confidently invoke the tool with correct parameter values, despite the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters, so the description must compensate. It adds semantic context for the pagination behavior (page/page_size) and for condition, but says nothing about source or format. Parameter names are somewhat self-explanatory, but the description does not fully clarify their values or intended use.
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 indicates the tool's function with 'preview' as the verb and 'data' as the resource, and adds two distinguishable behaviors: pagination and conditional filtering. It differentiates from siblings like sql_query, aggregate_stats, and data_insights, though it does not specify which data source is being previewed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as sql_query, query_video_stats, or data_insights. There is no mention of use cases, prerequisites, or when this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the core behavior (Pearson correlation matrix on numeric columns) and implicitly that it is read-only, but it omits behavior for non-numeric columns, missing values, source selection, and output formatting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. Every word adds information, and the core object (numeric-column Pearson matrix) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A simple output schema may cover return values, but the tool still has three undocumented parameters and no annotations. The description alone does not give an agent enough to know valid format/source values or behavior with defaults, so it is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the three parameters. It only clarifies that columns are optional; format and source are left unexplained. This is insufficient for correct invocation.
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 identifies the operation as computing a Pearson correlation matrix over numeric columns and notes optional column selection. This is specific enough to distinguish it from generic aggregate_stats or sql_query, though it is a noun phrase without an explicit verb and does not name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided, and no alternatives are mentioned. '可选指定列' hints at usage, but the agent gets no context about prerequisites, typical scenarios, or why to choose this over sql_query/aggregate_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It conveys a read-style operation that returns column names and types, but it does not explain how the source is resolved, what happens with the default source, or whether errors are possible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that states the action and expected result without filler. For a simple listing tool, this is appropriately concise and front-loaded.
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?
The tool is simple and an output schema exists, so the description does not need to explain return values in detail. However, the source parameter is undocumented and no relation to sibling tools is provided, so the agent still has to make assumptions about the only input and when this tool is preferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions the 'source' parameter. The phrase '数据集的' only indirectly hints that source identifies the dataset, leaving the only parameter's semantics largely implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('列出' / list) and a specific resource ('数据集的全部列名与类型' / all column names and types of the dataset). It is clear about the primary intent, though it does not explicitly differentiate itself from close siblings like get_schema or preview_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_schema, preview_data, or sql_query. No prerequisites, limitations, or exclusions are mentioned, so the agent must infer the appropriate usage context.
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 burden of behavioral disclosure. It indicates a read-only introspection operation returning schema statistics and examples, which is useful, but it does not mention behavior around the optional source parameter, defaults, caching, cost, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action and followed by a compact, well-structured enumeration of returned details. Every word earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema means return values do not need to be fully re-described, and the single optional parameter keeps the tool simple. However, the unexplained 'source' parameter and absence of any usage context or sibling differentiation leave meaningful gaps for an agent deciding how to invoke or route the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'source', has no schema description (0% coverage), and the tool description never mentions it or explains what values it accepts or how the default behaves. The agent is left to infer the meaning of 'source' and 'default' from the parameter name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource pair ('获取数据集详细 Schema') and enumerates specific output contents: column names, types, non-null counts, mean/quantiles, and value examples. This distinguishes it from a simple column listing, though it does not explicitly name sibling tools or contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when detailed schema and statistical summaries are needed, but it gives no explicit guidance on when to choose this over siblings like list_columns, preview_data, or aggregate_stats. There are no stated exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It states what the tool returns, which implies a read-only diagnostic action, but it does not explicitly say it is non-mutating, whether it triggers any refresh, or what failure behavior looks like. The listed outputs provide some transparency but not complete behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that immediately states the tool's purpose and enumerates its outputs. There is no redundant wording or filler.
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 no-parameter tool with an output schema, the description is reasonably complete: it names the categories of returned information and implies a health-check role. It could be improved by stating when to run it relative to sibling tools, but the low complexity keeps the gap small.
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 zero parameters, so the baseline is 4. The description does not need to explain parameter semantics because there are none; the described outputs are the relevant payload.
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 returns health-check information: data sources, row/column counts, required columns, and MCP tool count. The specific output list differentiates it from sibling tools like list_columns or get_schema, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as list_sources, get_schema, or data_insights. An agent would have to infer from the name and output list that this is a diagnostic/verification tool, but no explicit context or exclusions are given.
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, and it does state that the tool is read-only and only supports SELECT/WITH, which signals no data mutation. It does not mention output details or error behavior, but the output schema covers return 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and it front-loads the most important constraint: read-only SQL query restricted to SELECT/WITH. Every word adds meaningful information.
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?
The core query behavior and safety constraint are present, and an output schema exists, so return values do not need explanation. However, the semantics of format and source parameters are missing, and there is no explicit guidance on when this tool should be preferred over sibling query tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for undocumented parameters, but it does not explain sql, format, or source beyond implying SQL execution targets. The execution-target hint is weakly relevant to the source parameter, but the format parameter remains entirely unexplained.
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 identifies the tool as a read-only SQL query limited to SELECT/WITH and states that it runs on SQLite or DataFrames. It is specific about the verb and resource, though it does not explicitly differentiate itself from sibling tools like query_video_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by restricting queries to read-only SELECT/WITH statements, implying that write or non-query operations should not be attempted. It does not name alternative tools or provide explicit when-not scenarios beyond the read-only restriction.
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?
There are no annotations, so the description carries the full burden. It does clarify that the data sources come from DATA_FILE / DATA_SOURCES configuration and describes a list operation, which implies read-only behavior. However, it does not disclose potential side effects, staleness, or whether the list is dynamically refreshed or cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It front-loads the main action and resource, then adds the configuration detail parenthetically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with an output schema, the description is complete: it states what the tool returns conceptually (available data sources) and where that information comes from (configuration). No additional return-value or parameter details are necessary given the 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 tool has zero parameters and schema coverage is 100%, so there is no parameter burden for the description to carry. The baseline for zero parameters is 4, and the description appropriately says nothing about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('列出' / list) and a specific resource ('数据源' / data sources), making the tool's function immediately clear. It also distinguishes this tool from siblings like refresh_sources and list_columns by focusing on enumerating configured data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used to discover currently available data sources, especially before operating on them. However, it does not explicitly state when to prefer this tool over alternatives such as refresh_sources or get_schema, nor does it mention any 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states it is a read-only operation that does not modify files, which is valuable context for a cache-clearing tool. It does not mention global scope or performance effects, but those are minor for a parameterless refresh operation.
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 two short, purposeful clauses: it front-loads the main action, then states the effect and the read-only safety guarantee. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless cache-refresh tool with an output schema present, this description provides enough context: what the tool does, how it affects future queries, and that it does not modify files. An agent can select and invoke it correctly without further detail.
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 tool has zero parameters and the input schema is an empty object, so there are no parameter semantics to clarify. The baseline of 4 applies because no additional parameter explanation is needed.
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 opens with a specific verb and resource: '清除数据源缓存' (clear data source cache), and explains the practical effect: the next query re-reads CSV/SQLite. This clearly distinguishes it from sibling query/analysis tools like sql_query, preview_data, and list_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied—refresh presumably when cached data is stale so subsequent queries re-read the source—but the description does not explicitly state when to use this tool versus alternatives, nor does it give exclusions. It makes the intent understandable but leaves the decision somewhat to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![mcp-data-service MCP server](https://glama.ai/mcp/servers/lengzhanbao/mcp-data-service/badges/card.svg)](https://glama.ai/mcp/servers/lengzhanbao/mcp-data-service)

Score Badge

Copy to your README.md:

[![mcp-data-service MCP server](https://glama.ai/mcp/servers/lengzhanbao/mcp-data-service/badges/score.svg)](https://glama.ai/mcp/servers/lengzhanbao/mcp-data-service)

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/lengzhanbao/mcp-data-service'

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