data-analysis-agent

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct read vs. mutate roles, and analysis tools target different operations. However, get_dataset_info and describe_dataset overlap in reporting missing values, and compute_statistic largely duplicates portions of describe_dataset, which could cause some misselection.
Naming Consistency4/5
The naming is predominantly verb_noun and easy to follow, such as load_dataset, drop_column, and create_visualization. A few tools like frequency_analysis, correlation_analysis, and group_analysis break the imperative pattern by using noun_analysis instead of a verb construction.
Tool Count3/5
At 22 tools, the server provides broad coverage but feels somewhat heavy for a data analysis agent. The count is justified by the range of cleaning, statistical, and visualization operations, yet several tools overlap closely enough that the surface could be trimmed to around 15-18 tools.
Completeness3/5
The server covers loading, session management, cleaning, statistics, and visualization well, but has notable gaps for common data analysis tasks like row filtering, sorting, adding/deriving columns, joining datasets, or reshaping. These missing operations will require agents to work around the tool surface or fail on common requests.
Average 3.5/5 across 22 of 22 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explicitly state that the tool is read-only, whether a session must already exist, or what happens with an invalid session_id. 'Get' weakly implies non-mutation, but no real behavioral context is disclosed.
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, tightly written sentence that front-loads the action and enumerates exactly what information is returned. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return-value details are not required. However, the description lacks usage guidance, sibling differentiation, and parameter semantics, making it minimally viable but clearly incomplete for a no-annotations 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?
Schema description coverage is 0%, and the description does not explain session_id beyond saying 'for a session'. It does not describe where the session_id comes from, its format, or that it should be a session returned by list_sessions. The description does not compensate for the missing schema-level parameter 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 uses a specific verb ('Get') and names concrete resources and outputs: shape, column types, missing value counts, and memory footprint. It is clear and not a tautology, but it does not explicitly differentiate itself from similar siblings such as describe_dataset or find_missing_values, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like describe_dataset, preview_dataset, or find_missing_values. The phrase 'for a session' only identifies the target context, not the appropriate selection conditions.
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 behavioral disclosure. The 'Get' verb and 'audit log' clearly convey a read-only operation, and 'revertible status' adds useful context. However, it does not explain ordering, pagination, whether only applied transformations are included, or whether a valid session is required, which are important for a history tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with the main verb front-loaded and no filler. The placement of 'with revertible status' is slightly awkward and could be clearer, but the structure is otherwise appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter, an output schema, and many related sibling tools, the description is too thin. It omits the meaning of 'revertible status,' the purpose of the limit parameter, and any context about how this tool relates to undo/restore operations, leaving too much to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it only loosely references 'dataset session' for session_id and says nothing about the limit parameter or its default of 50. The agent must rely entirely on parameter names and schema metadata to understand 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 a specific verb 'Get' and a resource, 'audit log of all transformations applied to dataset session,' and adds the distinctive detail 'with revertible status,' which helps separate it from mutation tools like undo_last_operation and restore_session. However, the phrase 'with revertible status' is ambiguous — it could mean each entry includes a status or only revertible entries are returned — so it does not earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as undo_last_operation, restore_session, or list_sessions. The only signal is the tool name and 'audit log,' leaving the agent to infer when this tool should be selected.
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 present, so the description carries the full behavioral burden. It states what the operation does but does not disclose whether it mutates the session, requires a saved dataset, how it handles missing values, or what output the agent should expect. This is a meaningful transparency gap.
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 concise and front-loaded with the core purpose, followed by a useful example and allowed aggregations. The aggregation list is slightly redundant with the enum but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no annotations, and several analytical sibling tools, the description is not complete enough for confident selection and invocation. It omits usage guidance, the meaning of session_id and sample, and any behavioral notes. The presence of an output schema helps with return expectations but does not fill these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does clarify group_by as categorical dimensions, metric as the column to aggregate, and gives an example mapping parameters. However, session_id and sample are left unexplained, and the aggregation list merely repeats the schema enum.
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 a specific operation: aggregate a metric column grouped by categorical dimension(s), with a concrete example. This distinguishes it from unrelated siblings, but it doesn't explicitly contrast it with similar analytical tools like compute_statistic or frequency_analysis.
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, no exclusions, and no mention of related tools. The agent must infer usage context from the name and general wording.
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?
The description explicitly states 'Reversible,' which is a meaningful behavioral disclosure beyond the schema. However, with no annotations provided, it does not mention side effects on the session, what happens when 'drop' is used, whether original data is modified, or whether constant imputation requires a user-supplied value. The behavior is only partially disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only two short sentences with no redundant or filler content. The main purpose is front-loaded, and the reversibility note is a separate, valuable behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation-like operation with four parameters and no annotations, the description is too minimal to be fully actionable. An agent would not know that 'constant' likely requires a non-null value, how the operation interacts with session state, or when to prefer it over find_missing_values or undo_last_operation. The output schema helps, but the usage context remains 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 compensate for undocumented parameters. It names the strategies and the column, but it does not explain the 'value' parameter, which is essential for the 'constant' strategy, nor does it clarify the role of session_id. The description largely repeats the strategy enum already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as handling missing values in a column and enumerates five concrete strategies: mean, median, mode, constant, and drop. This is specific enough to distinguish it from the sibling tool find_missing_values, which presumably only detects missing values, though it does not name that distinction explicitly.
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, nor does it mention prerequisites such as having an active session or having previously used find_missing_values. The intended use is only implicit from the tool name and the generic phrase 'Handle missing values'.
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?
The description discloses reversibility, which is valuable for a mutation operation and partially compensates for the absence of annotations. However, it omits details such as session prerequisites, constraints on new_name, and potential impacts on dependent operations or downstream transformations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words. The purpose is front-loaded, and 'Reversible' adds a relevant safety detail without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-required-parameter mutation tool with no annotations and 0% parameter description coverage, this definition is too sparse. It lacks usage guidance and parameter semantics, relying entirely on schema titles; the output schema covers return values but not invocation details.
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 carry parameter meaning, but it only hints at column and new_name through the verb 'rename' and says nothing about session_id. This does not sufficiently compensate for the schema gap.
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 operation and target resource: 'Rename a column in the dataset.' The action 'rename' clearly differentiates from sibling tools like drop_column or convert_column_type, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use rename_column versus related transformation tools such as convert_column_type or drop_column. The word 'Reversible' is a behavioral note, not usage direction, and no context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. 'Analyze' and 'count' imply a read-only diagnostic operation, but there is no explicit statement that the dataset is not modified, and no mention of side effects or requirements beyond the session_id. This is minimally adequate but not fully transparent.
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 front-loaded sentence with no filler. It names the action, the subject, and the result in 13 words, which is ideal for tool selection.
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 one-parameter analysis tool with an output schema, the description covers the core operation. However, it omits explicit safety semantics and fails to distinguish itself from handle_missing_values, leaving an agent to infer when to choose it. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not mention session_id or explain that the analysis applies to the dataset associated with that session. The parameter name and title are self-explanatory, but the description adds no value for it.
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 uses a specific verb ('Analyze'), a clear target ('missing/null values per column'), and names the output ('count affected rows'). It is readily distinguishable from sibling 'handle_missing_values' because it signals analysis rather than transformation, though it never explicitly names that sibling.
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 when-to-use guidance or exclusions. Despite a nearby sibling tool named 'handle_missing_values', the description does not say to use this for diagnosis and the sibling for remediation, so an agent must infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for disclosing behavior. It only restates that cleaning operations are reverted, without mentioning side effects, risks, session-state requirements, irreversibility, or whether the undo stack persists across saves.
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 front-loaded sentence with no filler. It states the action, scope, and mechanism concisely, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no schema-level parameter descriptions, this description is thin. It leaves unanswered questions about prerequisites, undo limitations, and why an agent should select this tool over restore_session.
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%, but the wording maps "N" to the steps parameter and "dataset session" to session_id. This adds some meaning over the bare schema, though it never explicitly names the parameters or explains their constraints.
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 a specific action (revert), a target (the last N mutating cleaning operations on a dataset session), and a mechanism (generic undo). It is clear enough to understand what the tool does, though it does not explicitly distinguish itself from the sibling restore_session.
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 phrasing implies this tool should be used after mutating cleaning operations, since it reverses them. However, it gives no explicit guidance about when not to use it and does not mention alternatives like restore_session or get_transformation_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It states that saving writes to data/outputs/, but does not disclose overwrite behavior, directory creation, whether the path must include an extension, session validity requirements, or any other side effects of the write 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 one compact, front-loaded sentence with no wasted words. The example filename is useful and placed naturally, making the intended argument value immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and 0% schema description coverage, the description is incomplete. It tells the agent what saving does and where files go, but omits session_id semantics, format handling, and any guidance on how this relates to sibling session/dataset tools, so an agent cannot reliably call it without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies the path parameter somewhat through the example 'cleaned_sales.csv' and the output directory, but it does not explain the required session_id parameter or the optional format parameter, leaving critical invocation details undocumented.
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 states a clear verb ('Save'), resource ('in-memory dataset'), and destination ('data/outputs/ directory'), with an illustrative filename example. It is readily distinguishable from sibling tools like load_dataset and restore_session because it names the persistence action explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when the agent wants to persist the current in-memory dataset after transformations. However, it does not explicitly say when to prefer it over alternatives such as restore_session or when not to use it, so usage guidance is only implicit.
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 does disclose one important trait—'Reversible'—which signals that the operation can be undone. However, it does not explain what happens to incompatible values, missing data, or the session state beyond the fact of reversibility.
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 sentences with zero fluff. The main action and target types are front-loaded, and the reversibility note is a separate, valuable piece of information. Every word earns its place.
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 relatively simple transformation tool with an output schema, the description covers the core action and the reversibility trait. However, it lacks guidance on parameter semantics and edge-case behavior, and it does not place the tool in the context of sibling alternatives. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It repeats the target_type enum values already present in the schema but provides no added meaning for session_id or column, and does not explain how these parameters interact or what constraints apply. The added value over the structured schema is minimal.
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 ('Convert') with a clear resource ('column data type') and enumerates the exact allowed target types. This sharply distinguishes it from sibling tools like drop_column or rename_column without needing to inspect their schemas.
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?
Beyond noting that the operation is reversible, the description gives no guidance on when this tool should be used versus alternatives like handle_missing_values or rename_column. There are no preconditions, no exclusions, and no mention of how it fits into a transformation workflow.
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 disclose the operation ('Compute'), the output ('Returns correlation matrix and top ranked strongest positive/negative correlation pairs'), and the supported methods. However, it does not explicitly state that the operation is read-only or explain behavior around missing values, non-numeric columns, or sampling.
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 short and front-loaded with the main action. It loses a point for the redundancy of mentioning 'correlation matrix' twice, but it otherwise contains no filler.
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 is moderately complex, with four parameters and no annotation coverage, yet the description omits key contextual details such as what 'sample' does, what happens when 'columns' is null, and how the session dataset is used. The presence of an output schema reduces the need to describe return values, but the parameter-context gap remains significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially explains 'method' by listing valid values and 'columns' indirectly via 'numeric columns', but 'sample' and 'session_id' are not explained at all. The description is not enough to correctly set parameters beyond method.
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 ('Compute') with a clear resource ('correlation matrix between numeric columns') and lists the supported methods. This makes the tool's purpose immediately distinguishable from all sibling tools, none of which mention correlation.
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 usage whenever a correlation matrix or strongest pairwise correlations are needed, but it does not explicitly state when to use this tool versus alternatives like compute_statistic, describe_dataset, or create_visualization. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context. It discloses that the operation is 'Reversible', which is a meaningful safety-relevant trait. However, it does not describe what happens to dependent operations, whether data is merely hidden or removed, or other 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 extremely concise: two short sentences, no filler, and the core action is front-loaded. Every word adds meaning, and the 'Reversible' note earns its place as behavioral context.
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 simple two-parameter operation with an output schema, the description is minimally adequate: it names the action and adds a key reversibility detail. However, it omits usage context, parameter clarification, and side-effect detail, so it is not fully self-sufficient for an agent deciding when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the parameters. It only implicitly references 'column', but does not clarify the meaning of 'session_id', column-name requirements, or how the session is used. The agent gets little beyond the raw parameter names.
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 states a specific verb ('Drop'), a resource ('a column'), and the target context ('the dataset'). It is distinct from sibling tools like rename_column or remove_duplicates, so an agent can identify what this tool does immediately.
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 about when to use this tool versus alternatives, and no mention of prerequisites such as an active session. The intended usage is only implied by the tool name and the verb 'Drop'.
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?
Annotations are absent, so the description must carry the behavioral disclosure. It does add useful context: the file is local, loaded from disk into a session on the user's machine, rather than a remote or code-level operation. It does not disclose side effects such as whether loading replaces an existing session, memory limits, or file-size constraints, which matters for a stateful load 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, with the core action in the second sentence and the mandatory-use rule front-loaded. The first and third sentences are somewhat redundant in urgency but each adds a distinct fact: when to use and what not to use instead. Overall compact with little waste.
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?
With no annotations and 0% schema descriptions, the description is the only source of behavioral and usage context; it covers file location and supported formats. It omits semantics for the optional format and sample_rows parameters and any statement about session replacement, though an output schema does exist. It is adequate for a basic call but not complete for robust agent decision-making.
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 free-text description must compensate. It names supported formats (CSV, JSON, Excel, Parquet) and implies a filesystem path, which helps with the path and format parameters. It does not explain the format parameter's auto-detection behavior or the sample_rows parameter at all, so parameter guidance is incomplete.
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 concrete operation: loads a local dataset file from disk into a session, and it names supported file types. However, it also claims the tool is mandatory for analyzing, inspecting, or querying datasets, which blurs the line with sibling tools like get_dataset_info, preview_dataset, and describe_dataset. The core load action is clear, but the scope claim is somewhat overbroad.
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?
It explicitly states when to call it ('MUST be used whenever loading, analyzing, inspecting, or querying any dataset') and explicitly forbids alternatives ('ALWAYS call this tool instead of using bash, shell, or writing python code'). It does not name sibling tools as alternatives, but the alternative it does name is direct and relevant. The guidance is clear but does not explain sequencing relative to the analysis siblings.
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 disclosing side effects. It does state that the operation removes rows and is reversible, which is useful, but it does not describe the mechanism of reversibility or any other impact on the session/data beyond the row removal.
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?
A single front-loaded sentence that names the action, resource, method options, defaults, and reversibility with no filler words.
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 short description covers core purpose and method semantics, and the output schema covers return values. However, for a 4-parameter mutating tool with no annotations, it omits threshold semantics, session context, and guidance on when to use the tool versus find_outliers.
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 add meaning. It usefully explains the method defaults (1.5x for iqr, 3.0 for zscore) and implies column must be numeric, but it does not explain the threshold parameter's behavior or the role of session_id.
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?
States a specific verb ('Remove'), a resource ('outlier rows in numeric column'), and method options. This clearly separates it from sibling tools like find_outliers (detection only) and remove_duplicates (different cleaning operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose this over find_outliers or how to decide between iqr and zscore. The intended use is only implied by the tool name and description, and no exclusions or prerequisites are mentioned.
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, the description carries the full burden and does well by specifying the exact return contract: numeric summary statistics, categorical distinct counts, and top frequent values. It does not explicitly state side effects or read-only behavior, but the 'Get' framing and tool name make the read-only nature reasonably clear.
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 concise and well-structured, front-loading the core purpose and then listing the specific statistics returned. Every sentence adds concrete value with 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 output behavior is thoroughly described and an output schema exists, but the definition leaves key gaps: optional parameter semantics are absent and there is no guidance for choosing this tool over several closely related siblings. It is adequate for a default call with only session_id but not complete for more targeted use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the three parameters: session_id, sample, and columns are never mentioned. The agent must infer the role of sample and columns from their names and defaults alone, which is insufficient for reliable non-default invocation.
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 identifies the action and resource: 'Get comprehensive summary statistics for dataset columns.' It enumerates exact outputs such as nulls, mean, std, quantiles, positive/negative/zero counts, distinct count, and top frequent values, making it easy to distinguish from sibling tools like compute_statistic or frequency_analysis.
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 it should be used when a broad statistical overview is needed, but it does not explicitly state when to prefer it over similar tools like compute_statistic, frequency_analysis, or get_dataset_info. No alternatives, exclusions, or conditional usage guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses that the operation is reversible, which is useful for a mutation tool. However, it does not mention whether session state is modified in place, any prerequisites, or other 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?
One short sentence with no filler. The key scoping phrase is front-loaded and the reversibility note adds value without extra length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter transformation with an output schema, the description gives the core behavior and reversibility, but lacks usage context and side-effect details. It is minimally adequate but not complete enough to fully guide agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only clarifies the 'subset' parameter by mentioning 'all or a subset of columns'. Parameters 'keep' and 'session_id' are left entirely to their schema properties, so the description does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Remove duplicate rows') with a clear scope ('across all or a subset of columns') and adds reversibility. This clearly distinguishes it from sibling transformation tools such as drop_column or rename_column.
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?
No explicit when-to-use or alternative routing is provided, but the operation name strongly implies a data-cleaning/deduplication use case. There are no exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does add useful semantics for stats like positive_count and null_count, but it does not explicitly state that the operation is read-only or describe how missing values or sampling affect results.
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 followed by a list of supported stats. Every element is relevant and the main purpose is front-loaded. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, but the description omits the meaning of the sample parameter and does not mention column type requirements or missing-value handling. This leaves some ambiguity for an agent trying to call the tool correctly with all parameters.
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 does define the stat parameter and clarifies 'column', but it leaves session_id and sample unexplained. This partial coverage is helpful but not complete.
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 states a specific verb and resource: 'Compute a specific statistical metric on a column' and enumerates all supported metrics. This clearly distinguishes it from broader sibling tools like describe_dataset or frequency_analysis by emphasizing single-column statistical metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever a specific statistic on a column is needed. However, it does not explicitly contrast it with alternatives or state when not to use it, leaving the selection decision to inference.
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. It discloses that the operation restores a disk session into active memory, but it does not mention whether the current session is overwritten, whether unsaved work is at risk, or how invalid IDs are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the action stated first and the prerequisite lookup second. There is no filler and every sentence earns its place.
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 with one required parameter and has an output schema to cover return values. The description covers the core action and how to find a valid ID, but omits state-change risks such as overwriting the active session, which would be helpful for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only declares session_id as a required string with no description, and coverage is 0%. The description partially compensates by telling the agent to call list_sessions to obtain valid saved session IDs, but it does not explain ID format or error behavior.
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 ('restore') with a clear resource ('saved disk session') and target state ('active memory'). It also references list_sessions, which distinguishes this session-restoration tool from dataset-loading siblings like load_dataset.
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?
It provides a clear precondition: call list_sessions to discover available saved session IDs. It does not explicitly discuss when not to use the tool or compare it against alternatives, so it stops short of a full usage-guide, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. 'Calculate' implies a read-only operation, and an output schema exists, so return-value details are covered elsewhere. However, the description does not disclose how missing values, sampling, or session state are handled, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the core purpose, adds the categorical/discrete qualifier, and states the top-N behavior, all without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and has an output schema, but the description omits important context such as how the 'sample' parameter behaves and when this tool should be preferred over similar siblings like 'compute_statistic' or 'group_analysis'. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the parameters. It indirectly explains 'column' and 'top_n' through 'categorical or discrete columns' and 'top N', but it does not explain 'sample' or 'session_id'. This is a meaningful gap for correct invocation.
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 states a specific verb ('calculate'), a clear resource (frequency distribution/value counts), and a scope ('categorical or discrete columns'). The phrase 'top N most frequent' clarifies the output, and the categorical/discrete qualifier helps differentiate this from numeric statistics tools.
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 gives clear usage context: use for categorical or discrete columns and request the top N most frequent values. It does not explicitly name sibling tools or provide when-not-to-use guidance, but the intended use case is clear enough for selection.
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, the description carries the burden, and it does disclose meaningful constraints: the `capped at max 50 rows` limit and the sample-vs-top variant. It does not explicitly confirm the operation is non-destructive, but `preview` and the absence of mutation language make that a minor 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler; the behavioral cap appears immediately and the sentence is fully informative. It earns its place without redundant phrasing.
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 simple preview tool with an output schema and only three parameters, the description covers the core behavior. It remains slightly thin on parameter-level detail and explicit read-only guarantees, but these are not critical for this tool.
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 compensation matters. `sample or top rows` maps clearly to the `sample` boolean, and the 50-row cap contextualizes `n`; however, `session_id` is left unexplained and the exact cap/`n` interaction is not spelled out.
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 names a clear verb (`Preview`), a resource (`dataset`), and the exact scope (`sample or top rows`, capped at 50). This makes it easy to distinguish from siblings such as `load_dataset` or `describe_dataset`, which serve different purposes.
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 quick row-level inspection but does not explicitly state when to choose `preview_dataset` over `load_dataset` or `describe_dataset`, nor any exclusions. The use case is inferable from `preview`, but the guidance is not made explicit.
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 behavioral transparency burden. It explicitly discloses non-destructive behavior and the specific outputs: outlier count, percentage, bounds, and sample row IDs. It does not cover edge cases like non-numeric columns or threshold interactions, but it provides solid transparency for a read-only tool.
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 dense sentence with no filler. It front-loads the core purpose and includes only information that helps an agent understand and use the 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?
The description covers core purpose and return values, and the output schema exists, so return value detail is not required. However, with 5 parameters and 0% schema description coverage, the optional 'sample' and 'threshold' parameters remain unexplained, leaving the definition incomplete for full invocation confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter meaning. It adds context about numeric columns and method choices, but it does not explain the 'sample' or 'threshold' parameters, their defaults, or how they affect the calculation. An agent would not know what values to pass beyond the required session_id and column.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs read-only outlier inspection on a numeric column using 'iqr' or 'zscore'. It explicitly says it does not alter the dataset, which directly differentiates it from the sibling tool 'remove_outliers'.
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 conveys its use case through 'Read-only' and 'without altering the dataset', signaling it is for detection/inspection rather than transformation. It does not explicitly name an alternative tool, but the sibling list and non-destructive language make the intended usage reasonably clear.
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 disclosure burden and does well: it reveals the return shape ('complete base64 image inline in thumbnail_b64 and saved file path') and warns against a specific failure mode ('DO NOT run bash or shell commands to locate or move the file'). It does not cover cost/performance traits of the sample parameter, but the key operational behaviors are disclosed.
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 dense but efficiently structured: purpose first, then a compact parameter reference, then return format and the critical behavioral warning at the end. The parameter list is somewhat long, but each element carries distinct information that the 0%-coverage schema fails to provide.
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 11 parameters, no annotations, and no output schema, the description covers chart-type options, most parameter semantics, return format, and a behavioral warning. Remaining gaps are per-chart-type parameter requirements (e.g., which params are needed for scatter vs heatmap) and the meaning of 'sample' — notable but not crippling for a visualization tool.
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, and it explains 8 of 11 parameters with semantic meaning: x as horizontal column, y as vertical column, group_by as color/hue dimension, bins for histograms, columns for correlation heatmaps. However, 'sample' (default 50000) is never explained, leaving an important numeric parameter undocumented.
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: 'Generate a chart visualization from the dataset session.' It enumerates ten supported chart types and clearly differentiates itself from all 22 siblings, none of which are visualization tools. An agent can immediately identify this as the only chart-creation tool in the set.
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 phrase 'from the dataset session' implies the tool requires a prior load_dataset call and a valid session_id, but no explicit when-to-use guidance, exclusions, or alternatives are stated. Usage context is inferable from the tool's unique role among siblings rather than from direct instruction.
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, the description carries the burden of behavioral disclosure. It clearly indicates the operation is a non-destructive enumeration and adds useful context about covering both active in-memory and saved sessions, plus the returned fields. It stops short of explicitly saying it causes no side effects, but 'List' strongly implies read-only behavior.
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?
A single, well-structured sentence front-loads the action and resource, then adds relevant scoping details and field names without any filler. Every element contributes to understanding the tool.
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?
Given that the tool takes no parameters and an output schema exists, the description is fully sufficient. It covers what is listed, the scope (in-memory and disk), and the output fields, leaving no meaningful gap for correct invocation.
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, so there are no semantics to add beyond the empty schema. The baseline of 4 applies, and the description correctly focuses on output scope rather than inventing parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('all dataset sessions'), explicitly covering both active in-memory and saved-on-disk sessions. It also enumerates the included fields, making the tool's purpose unambiguous and distinct from sibling tools like restore_session or load_dataset.
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 makes it clear that this is the tool to use when enumerating sessions across both in-memory and disk state. It does not explicitly name alternatives or exclusions, but the listing scope is stated clearly enough to guide selection among the siblings.
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-mcp MCP server](https://glama.ai/mcp/servers/Soham-Donode/data-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Soham-Donode/data-mcp)

Score Badge

Copy to your README.md:

[![data-mcp MCP server](https://glama.ai/mcp/servers/Soham-Donode/data-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Soham-Donode/data-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/Soham-Donode/data-mcp'

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