edamcp

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 clearly distinct purposes, but auto_compare and compare_sources both perform schema diff + drift analysis and return a safe/risky/incompatible verdict, making them easy to confuse. A few other pairs (auto_quality vs. run_eda, plot_facet vs. plot_distribution) are related but descriptions clarify their roles.
Naming Consistency4/5
The vast majority of tools follow a verb_noun pattern (check_*, clean_*, plot_*, auto_*, detect_*), but a few outliers like data_card, eda_storyboard, and profile break the pattern. The auto_* prefix also mixes verbs and nouns, but overall the conventions are largely consistent.
Tool Count1/5
With 69 tools, the server is far beyond the typical 3-15 well-scoped range, and exceeds the 50+ extreme threshold. The sheer number forces agents to scan a massive list for every decision, hurting usability despite the broad feature set.
Completeness5/5
The tool surface covers the full data lifecycle: loading, exploring, profiling, quality checking, cleaning, plotting, comparison, reporting, and export. There are no obvious dead ends, and composite macros like auto_explore, auto_quality, and run_eda stitch the pieces together well.
Average 4/5 across 69 of 69 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It does state the output format (JSON + inline PNG), which is a useful behavioral trait for the agent. However, it omits other important behaviors such as whether it is read-only, how parameters affect output, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, stating the core purpose and output format in two short fragments. It contains no fluff or redundancy. The second fragment 'JSON + inline PNG' is elliptical but still informative, making this an efficient, appropriately sized description for the little it conveys.
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 absence of annotations and output schema, the description is under-specified. It fails to explain what the JSON contains, how to use the method and columns parameters, or what the heatmap encodes. The tool has multiple parameters and no formal documentation, so this description is insufficient for reliable invocation.
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?
The description makes no mention of the three schema parameters (source_id, method, columns). Schema description coverage is 0%, so the agent gets no semantic information about what these parameters do, the meaning of the default method, or how columns can be used. This is a severe 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 clearly identifies the tool as generating a correlation matrix heatmap, which distinguishes it from other plot types. It specifies the output format (colored heatmap) but lacks an explicit verb like 'plot' or 'generate'. The resource (correlation matrix) is specific, making the purpose readily understood.
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 check_correlations, check_multicollinearity, or plot_scatter. The description does not mention any context, prerequisites, or exclusions, leaving the agent without selection criteria.
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 behavioral disclosure burden. It does disclose the output format ('JSON + inline PNG') and the optional grouping behavior, which are useful. However, it omits other behavioral details like interaction with source_id, limitations on group_by categories, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 8 words with no fluff, but it is so brief that it borders on under-specification. It lacks the structured context that would help an agent understand the tool's purpose and parameters fully.
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 3 parameters, no output schema, and numerous sibling plot tools, this description is insufficient. It does not explain the required `source_id` and `columns` parameters, contrast with alternatives, or provide enough context to invoke the tool correctly.
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 schema has 0% description coverage, so the description must compensate. It adds meaning only for `group_by` by noting it is categorical, but says nothing about `source_id` or `columns`. For a box plot, it would be helpful to specify that `columns` should contain numeric fields, but this is absent.
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 producing a box plot, which distinguishes it from sibling plot tools like scatter, violin, and distribution. The phrase 'Box plot' is a specific resource and action, though it lacks an explicit verb like 'create' or 'generate'.
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 a box plot versus alternatives such as violin or distribution plots. The description does not mention any context, exclusions, or preferred scenarios, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output format (JSON + inline PNG) but offers no other behavioral traits. With no annotations, it fails to indicate whether the operation is read-only, any side effects, or data type requirements, leaving a significant 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 extremely concise, using only two sentence fragments. It contains no superfluous words and directly conveys the plot type and output format, which is efficient for a simple tool.
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?
While the tool is simple, the description omits essential context such as expected column types, what the JSON contains, and when to prefer this over other plot tools. The absence of an output schema makes the vague reference to JSON insufficient for full comprehension.
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?
The schema defines two required parameters, column and source_id, but the description provides no explanation of their meaning or usage. With 0% schema description coverage, the description should compensate, but it does not mention parameters at all.
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 the tool creates a Q-Q plot versus a normal distribution, which is a specific plot type that distinguishes it from other plot tools like plot_scatter or plot_distribution. It also mentions the output format (JSON + inline PNG), further clarifying its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention it is for checking normality, nor does it exclude other use cases, leaving the agent without clear decision support.
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 burden of behavioral disclosure. It does disclose the output format ('JSON + inline PNG'), which is useful, but it omits other behavioral aspects such as whether the operation is read-only, any side effects, or how missing data is handled. This is a minimal but non-zero level of transparency.
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 very short and front-loaded with the purpose, but it is under-specified. The two sentences are efficient, yet they sacrifice essential guidance, resulting in a structure that is concise but incomplete.
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?
With 3 parameters, no annotations, and no output schema, the description is not complete enough for reliable invocation. It fails to explain what the JSON contains, what types of columns are expected, or how group_by modifies the plot. The 'JSON + inline PNG' hint is the only return-value information provided.
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 parameters. It does not describe source_id, column, or group_by at all. While 'Density-violin' implies column is the numeric variable, this is not explicit, and group_by is 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 producing a 'Density-violin plot', which specifies the plot type and distinguishes it from siblings like plot_boxplot or plot_scatter. However, it lacks an explicit verb (e.g., 'Creates'), making it slightly less direct than ideal.
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 this tool vs. alternatives. The description does not mention appropriate use cases, data requirements, or comparisons to sibling plotting tools like plot_distribution or plot_boxplot.
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 the return format ('JSON + inline PNG'), which is a useful behavioral trait. However, with no annotations, it omits other details such as handling of missing values, aggregation behavior, or whether it is read-only, leaving the agent to assume based on the tool type.
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 extremely concise with two short phrases that are front-loaded with the core purpose. It avoids unnecessary fluff, though it might be too sparse for a tool with five parameters.
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 there are five parameters and no annotations or output schema, the description is inadequate. It fails to explain what each parameter does, what constitutes valid inputs, or what the returned JSON+PNG structure looks like, making it incomplete for reliable 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%, and the tool description does not explain any parameter. Parameter names (source_id, time_column, value_columns, agg, granularity) carry some self-descriptive weight, but the description adds no specific meaning or usage examples, so it provides little value beyond the raw 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 'Line plot over time' clearly identifies the tool's function as creating a time-series line plot. This distinguishes it from other plot siblings like plot_scatter or plot_boxplot, though it could be more explicit about what data it operates on.
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 regarding when to use this tool versus other plot tools, such as plot_distribution or plot_scatter. The usage context must be inferred entirely from the name and minimal description.
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 two useful behavioral traits: auto-sampling beyond the `sample` parameter and the output format (JSON + inline PNG). Since there are no annotations, this is valuable. However, it does not mention what happens with missing values, non-numeric columns, or whether the tool has any side effects, which would be relevant for a plotting 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 extremely concise, using only three short fragments. It front-loads the core purpose and packs sampling and output format into two additional clauses without wasted words. Every sentence earns its place.
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 5 parameters, no output schema, and no annotations, the description is incomplete. It does not specify what the JSON part of the output contains, how to interpret the PNG, or the role of `color` and `source_id`. The lack of usage guidance also makes it hard to decide when to invoke this tool over siblings, especially with many other plotting tools present.
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 only implicitly covers x and y, and mentions `sample` in passing ('Auto-samples >`sample` rows'), but does not explain the exact meaning of `sample` (whether it's a target number or threshold). The `color` and `source_id` parameters are entirely unaddressed, leaving significant gaps for the agent.
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 creating a scatter plot of x vs y, which is specific and distinguishes it from other plot types like distribution, boxplot, or heatmap. However, it uses a noun phrase rather than an explicit verb like 'plot' or 'visualize', so it could be clearer, but the meaning is unambiguous.
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 explicit guidance is given about when to use this tool versus alternatives such as plot_correlation_heatmap or plot_timeseries. The purpose implies usage for two-variable relationships, but there are no exclusions, prerequisites, or alternative recommendations, leaving the agent to infer the appropriate 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?
With no annotations, the description discloses key behavioral traits: it returns JSON plus an inline PNG, and ncols controls grid width. However, it does not describe error handling, data requirements, or whether the source must be loaded, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is compact and front-loaded with purpose, then output format and a useful naming note. No wasted sentences, though the rename note could be considered tangential for an AI agent.
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?
No output schema and no annotations, so the description must carry more context. It fails to explain key required parameters like source_id and column, and only vaguely mentions JSON output without structure, making it insufficient for a 5-parameter 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?
Only ncols gets semantic explanation (controls grid width); source_id, column, facet_by, and bins are left entirely to their names. With 0% schema coverage, the description should compensate far more for these parameters.
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?
Description clearly states it creates a distribution faceted by a categorical variable ('small multiples'), which differentiates it from sibling tools like plot_distribution and plot_boxplot. It also specifies the output format (JSON + inline PNG).
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?
Implied use case is when a distribution should be broken down by a categorical variable, but there is no explicit comparison to plot_distribution or guidance on when not to use it. The rename note clarifies ncols but not selection criteria.
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 must carry the full burden of behavioral disclosure. It only mentions the output format (JSON + inline PNG) but does not clarify side effects, whether it requires a loaded source, how the PNG is encoded, or edge cases (e.g., all values present). This is insufficient for a tool with no annotation safety hints.
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 exceptionally concise, using only two short sentences to convey the core purpose and output format. There is no redundant wording, and the essential information 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?
Given the simple schema (one param), lack of annotations, and absence of an output schema, the description is minimally adequate but misses important context. It does not explain when to use the tool, what the JSON contains, or how to interpret the PNG, leaving the agent with an incomplete picture for a plotting 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 schema has one parameter (source_id) with 0% description coverage, and the description does not mention it at all. Although the parameter name and tool context imply it identifies the data source, the description fails to explicitly explain its meaning or usage, leaving a gap for the agent.
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 defines the tool as a per-column null-percentage bar chart, which is a specific and distinct purpose among sibling plot tools. It also states the output format (JSON + inline PNG), leaving no ambiguity about what the tool does.
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 like plot_distribution or check_* tools. It does not mention any exclusions, prerequisites, or comparison to sibling tools, leaving the agent to 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the output format ('JSON + inline PNG') but does not disclose that the operation is read-only, how sampling works, how 'top numeric columns' are selected, or any handling of missing data. This is insufficient for a tool that could be used on large datasets.
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, well front-loaded, with no wasted words. It conveys the core functionality and output format in a compact, efficient manner.
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 relatively simple but still has ambiguities: what determines 'top' numeric columns, how sampling is applied, and what the JSON output contains are left unspecified. Given no output schema and no annotations, the description is not complete enough to allow an agent to invoke the tool with confidence, especially compared to the many similar plotting siblings.
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?
The schema has no parameter descriptions, and the description does not compensate. It does not explain the role of 'source_id', the meaning of 'sample', or the format/behavior of 'columns'. The only hint is 'top numeric columns', which loosely relates to the 'columns' parameter but is not explicit. The description adds no real meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific phrase "N×N scatter matrix across top numeric columns" which clearly states the tool's function and distinguishes it from siblings like plot_scatter (single scatter) and plot_correlation_heatmap (heatmap). The verb is implied but unambiguous, and the resource is the numeric columns of the source.
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 for exploring pairwise relationships among numeric columns, but it gives no explicit guidance on when to prefer this over alternatives, nor does it mention any exclusions or when not to use it. It lacks explicit 'when to use' context beyond the inherent nature of a scatter matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It outlines the chain of operations but does not mention whether the tool is read-only, whether it modifies data, requires authentication, or has other side effects. For a macro that includes 'load_source', this lack of safety information is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, starting with 'The flagship blind-audit macro' and a one-line function statement. The chain is presented compactly, and the entire description is minimal while still conveying the tool's core purpose and flow.
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?
Despite having an output schema, the description omits critical context: what the returned introduction actually contains, what input path expects, what hints do, and whether any side effects occur. For a complex macro chaining multiple steps, this is not complete enough for an agent to use it safely and effectively.
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?
The schema has 0% description coverage and the description does not explain the meaning of 'path' or 'hints'. The only hint is the phrase 'unknown dataset' suggesting path points to a dataset, but this is not explicit. With two parameters, one required, and no parameter documentation, the description fails to add value beyond the raw schema field 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 clearly identifies this as an auto-exploration macro that returns a paste-ready introduction to an unknown dataset. It distinguishes itself from sibling tools by describing the chained pipeline (detect_pattern → detect_metadata → load_source → modality classify → data_card), establishing a specific verb+resource+scope.
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 context for when to use the tool: when you have an unknown dataset and want a full automated introduction. It implies this is the go-to macro compared to running individual steps, but it does not explicitly state when not to use it or name alternative 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, the description carries the transparency burden. It discloses the scan types, verdicts, and redact-list behavior, but lacks details on operational implications (e.g., read-only, prerequisites, how 'critical quality' is judged).
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?
Extremely concise; every line adds value: the question frames the use case, the verdicts define outcomes, and the redact-list note signals return structure. No wasted 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 description covers basics but leaves gaps: no guidance on when to choose this over individual check tools, no mention of whether it's mutating, and 'critical quality' is undefined. The output schema may fill return-format details, but operational context is thin.
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 one parameter (source_id) is not mentioned in the description. Schema coverage is 0%, so the description should have explained it; the name is self-explanatory but no additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: assessing external share-safety via PII, bias, and quality checks. The verdict list distinguishes it from sibling check tools, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening question implies the use case (sharing externally), but there's no explicit guidance on when to use this combined tool versus individual sibling checks like check_pii or check_bias.
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. It adds useful context such as supported formats, auto-naming for directory paths, and return of path/counts/file size. However, it does not mention overwrite semantics or side effects on existing files, which is a notable gap for a 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 compact and front-loaded with the primary verb 'Write', then efficiently lists formats, path rules, and return values. Every line earns its place with relevant detail, and there is no redundancy 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?
The tool is moderately complex with 4 parameters, no annotations, and an output schema. The description covers core behavior, format options, path handling, and return summary, making it quite complete. However, it omits explicit usage guidance and overwrite behavior, which would make it fully comprehensive.
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 zero description coverage, so the description must compensate. It adds meaning for 'format' by listing valid values (parquet, csv, json, ndjson) and for 'path' by explaining directory vs. full file path behavior. However, it leaves 'source_id' and 'overwrite' without additional explanation beyond their parameter names.
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 writes a source to disk via DuckDB COPY, listing supported formats and path behavior. However, it does not explicitly differentiate itself from the sibling tool 'unload_source', so it lacks explicit distinction while still being specific and informative.
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 like unload_source or load_source. It only implies usage for exporting a source, without exclusions or references to other tools.
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 were provided, so the description carries the full burden. It transparently discloses the output behavior: a single HTML file with no external assets, base64 embedded plots, a path-only return, and an approximate size of 100–500KB. It also outlines the report's sections. This goes beyond a simple one-liner and gives useful behavioral context without contradicting any annotations.
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 reasonably concise and well-structured, with the primary action front-loaded. Every sentence adds relevant detail (report contents, no external assets, output size). It is slightly verbose in places (e.g., 'emailable, attachable' could be seen as redundant), but overall each clause 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 description covers the output format thoroughly (path-only, HTML size, embedded plots), and there is an output schema defined, so return values are already specified externally. However, it is incomplete in explaining the hints and audience parameters, and does not clarify how this tool compares to sibling reporting tools like data_card or eda_storyboard. This leaves the description 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?
With 0% schema description coverage, the description had to compensate for the three parameters (source_id, hints, audience). It only mentions source_id in the sentence 'Generate a self-contained HTML report for source_id.', and says nothing about the meaning or usage of 'hints' or 'audience'. This leaves two parameters completely unexplained, which is a significant gap for a tool with a small parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's main action: 'Generate a self-contained HTML report for source_id.' It also lists specific contents (identity header, verdict, findings, embedded plots, profile table, sample rows), making the purpose concrete. However, it does not explicitly differentiate from similar sibling tools like data_card or eda_storyboard, so it loses one point.
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 context by mentioning 'offline-viewable', 'emailable, attachable', and 'path-only' output, which suggests when this report format is useful. It does not explicitly state when not to use it or mention alternative tools for different needs, so the guidance is implied rather than explicit.
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 disclose behavior. It states that a new source is produced and that columns are renamed per a mapping, which covers the primary behavioral trait. However, it does not mention validation, preservation of unmapped columns, or error handling.
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, direct sentence with no filler, front-loading the core purpose. It is appropriately concise for a simple tool, though it sacrifices some explanatory detail for brevity.
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 captures the core operation and hints at non-mutating behavior via 'new source'. Given the output schema exists, return values are covered, but edge cases and parameter semantics beyond mapping are missing. For a straightforward rename tool, this 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?
The description explains the mapping parameter format (`{old: new}`), but it does not elaborate on source_id or alias. With 0% schema description coverage, the description only partially compensates, leaving the other parameters underdocumented.
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 that the tool creates a new source with columns renamed per a mapping, using a specific verb and resource. It distinguishes itself from sibling cleaning operations like clean_drop_columns or clean_cast by focusing on renaming.
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 when column renaming is needed, but it provides no explicit guidelines on when to prefer this tool over alternatives or any prerequisites. The purpose is clear, but there is no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, what the output looks like, any side effects, or what 'safe and clean' concretely evaluates. While it implies an audit/check operation, it lacks behavioral detail.
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 that immediately conveys the tool's purpose and scope. 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?
Given the tool has an output schema (not shown here), return values may be covered by that. However, the description lacks contextual detail about the process, prerequisites, or limitations. For a tool combining multiple checks, it is minimally adequate but could benefit from mentioning that it aggregates standard checks into a report.
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 coverage is 0%, and the description does not explicitly explain the 'source_id' parameter. The name is self-explanatory to an extent, and the description refers to 'data' which hints at the source, but it adds no semantic detail beyond the schema's basic type and name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool covers quality, duplicates, PII, and bias in one call. This gives a specific verb (checks/evaluates) and resource (data quality dimensions), and distinguishes it from sibling tools like check_duplicates, check_pii, and check_bias by combining them.
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 phrase 'in one call' implies this is a comprehensive alternative to running individual check tools separately. It provides clear context for when to use it (when a quick multi-faceted quality assessment is needed), though it does not explicitly name alternatives or exclusions.
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 output characteristics (per-column stats, ~1-3KB per column) and performance (single DuckDB SUMMARIZE pass, fast on millions of rows), which adds behavioral context. However, with no annotations provided, it does not explicitly state that the tool is read-only or whether it has side effects, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and uses bullet points for clarity. Every sentence adds value—purpose, statistics details, performance, and output scaling—with no 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 existence of an output schema means return values are already documented. The description covers output content and performance, but misses parameter semantics and explicit usage guidance. For a simple 2-parameter tool, this is moderately complete but has 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 carries the full burden of explaining parameters. It fails to explain what 'source_id' refers to or how the optional 'columns' parameter behaves (e.g., omitting means all columns). Only the output behavior is described, not the inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('profile') and resource ('per-column'), and enumerates the exact outputs (type, null%, cardinality, stats). It distinguishes itself from siblings like describe_source or check_distributions by focusing on column-level profiling with a DuckDB SUMMARIZE approach.
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?
Usage context is implied through the performance claim ('fast on millions of rows') and the detail about output size, suggesting it's for quick column profiling. However, there is no explicit statement about when to choose this over alternatives like describe_source or check_distributions, nor any exclusions.
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 must carry the full transparency burden. It discloses the analytical steps (schema diff, drift) and output categories (safe/risky/incompatible), but does not explicitly state whether the operation is read-only, what 'drift' entails, or any potential side effects, leaving critical behavioral traits implied.
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 line that leads with the core question, then concisely outlines method and output. It is immediately scannable 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?
For a tool with three parameters and no annotations, the description is too terse to be fully self-sufficient. It clarifies the main sources but omits the 'keys' parameter, the meaning of 'drift', and any prerequisites. The output schema may cover return structure, but the overall context is incomplete for an agent to use it reliably.
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 effectively maps source_a to 'A' and source_b to 'B' through the drop-in question, clarifying their roles. However, the 'keys' parameter is never mentioned, leaving its function and relevance completely unexplained.
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 defines the tool's core purpose: evaluating whether source B is a safe drop-in replacement for source A using schema diff and drift, culminating in a verdict. It differentiates from other comparison tools by emphasizing the compatibility question and the three-way verdict outcome.
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 question 'Is B a safe drop-in for A?' implies the primary use case of assessing replacement safety, but it does not explicitly contrast with similarly named siblings like compare_sources or detect_schema_evolution, nor does it provide when-not-to-use guidance.
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 exist, so the description carries the full burden. It discloses the algorithmic approach (standardizes, SVD-based PCA), output details (variance-explained curve, intrinsic dim with thresholds, Hopkins statistic interpretation), and constraints (Caps at 50 features, output size small). This is transparent but doesn't mention how non-numeric columns or missing values 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense, with the key technique in the first line. The 'Level 3' tag and technical jargon might be opaque to some users, but overall it's efficient.
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 lists expected outputs and thresholds, which is useful, but lacks guidance on when to use the tool, parameter behavior, and edge cases. The presence of an output schema reduces the need to describe return types, but the input parameters remain underspecified.
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 coverage is 0%, and the description does not explain the parameters source_id or columns. The mention of 'numeric matrix' and 'Caps at 50 features' indirectly relates to columns, but there's no explicit semantics for what columns accepts or its default 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 clearly states it performs PCA-based dimensionality analysis and Hopkins clustering tendency, listing specific outputs (variance-explained curve, intrinsic dim, effective rank, Hopkins statistic). This distinguishes it from sibling check_* tools which focus on other aspects.
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 'use when' instructions or alternatives are mentioned. The description implies usage for dimensionality assessment but doesn't differentiate from similar tools like check_multicollinearity or check_feature_signal. The 'Level 3' tag and 'Caps at 50 features' provide some context but not explicit guidance.
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 disclosing behavior, and it does so well by specifying the exact SQL semantics (`SELECT DISTINCT *` and `ROW_NUMBER`). It also implies non-destructive behavior by saying 'New source'. However, it does not clarify what determines the 'first row' when using keys (no ordering specified), which is a notable 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?
The description is extremely concise and well-structured. The first sentence states the outcome, and the two bullet-like lines cover the distinct modes. Every sentence provides necessary information with no wasted 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 description covers the core behavior and the output schema is present, so return values don't need explanation. However, it omits the purpose of the `alias` parameter and fails to warn that 'first row' is undefined without an explicit ordering, which is important for a deduplication tool. These gaps prevent it from being 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. It explains the `keys` parameter in detail, but it does not describe `source_id` or `alias`. Since only one of three parameters is addressed, the compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it creates a new source with duplicates removed. It further distinguishes between two modes (full-row deduplication and key-based deduplication), making the tool's behavior specific and differentiated from sibling cleaning tools.
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 provides mode-specific guidance by explaining when to use `keys` versus not, but it does not explicitly discuss when to choose this tool over alternative cleaning tools or mention exclusions. Usage context is implied rather than stated.
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 does well: it discloses default vs optional methods, target-correlation leakage flag (r>0.95), the 50-column cap, and output structure (top 50 pairs + full matrix artifact). It does not mention permissions, error cases, or missing-data behavior, so not a 5.
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 reasonably compact and front-loaded with the core purpose, then parameter specifics and output behavior. Minor artifacts like 'Level 2' and line breaks are acceptable; each sentence contributes useful information.
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?
The description explains key limitations (50-column cap), output destinations (result vs artifact), and target-leakage behavior, and an output schema exists to cover return fields. It does not explain source_id semantics or when-to-use guidance, which keeps it from being fully complete.
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 coverage is 0%, but the description adds meaning for 'methods' (pearson default, spearman optional) and 'target' (triggers target-correlations and leakage flag). 'source_id' is not described, though it is inferable from the tool context. This is partial but not full compensation.
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 tool as 'Pairwise correlation analysis (Level 2)' and specifies its behavior: methods, target handling, leakage flagging, column cap, and output. This distinguishes it from sibling tools like check_multicollinearity, check_leakage, and plot_correlation_heatmap.
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 (when pairwise correlations are needed) and details options like methods and target, but it does not explicitly state when to prefer this over alternatives or mention exclusions/prerequisites. No sibling alternatives are named.
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 burden. It discloses several behavioral traits: flags specific distribution issues, suggests transforms, and notes 'Output size: small'. This gives a clear sense of behavior and non-destructiveness, though it does not explicitly state that no data is modified or describe edge cases.
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 three concise sentences, front-loaded with the core purpose, followed by specific checks and a note on output size. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain return values. It adequately covers what the tool does, the nature of checks, and output size. However, it lacks usage guidance and parameter semantics, leaving the agent to infer some context, so it is slightly incomplete for a complex analytical 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 coverage is 0% and the description does not elaborate on parameters. It mentions 'numeric column', which is a useful hint for `columns`, but does not explain that `columns` is optional and null means all numeric columns. `source_id` is left entirely to the schema's title, offering no additional semantics.
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 specifies the tool's function: 'Distribution shape per numeric column' with concrete checks (heavy skew, multimodality, zero-inflation, heavy tails) and suggested transforms. This distinguishes it from sibling tools like `check_outliers` or `plot_distribution`, which focus on different aspects.
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 includes 'Level 1', implying it is an initial exploratory check, but it does not explicitly state when to use it instead of alternatives such as `profile`, `describe_source`, or `plot_distribution`. No exclusions or alternative tool references are provided.
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 full burden. It discloses the specific checks performed, notes output size is small, and mentions a full report in an artifact. However, it does not explicitly state whether the tool is read-only or if it writes/modifies anything, though 'checks' implies non-mutating. Missing side-effect or permission details prevents a 5.
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: three sentences, each informative. It front-loads the primary purpose, lists detections, and closes with output behavior. No fluff or repetition; every sentence earns its place.
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 a single required parameter, an output schema, and no annotations, the description covers purpose, detections, and output size well. However, it lacks clarification of the source_id parameter and explicit usage differentiation among many sibling quality-check tools, so it is 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?
The input schema has no description for source_id (0% coverage), and the tool description does not mention source_id at all. The agent must infer from the name that it refers to a data source. The description does not clarify what source_id is, where to get it, or any format expectations, leaving a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Reality + univariate quality checks' and enumerates specific detections (schema sanity, empty/constant columns, missingness, sentinel values, string-numeric issues), making the purpose concrete and distinct from other check_* siblings that focus on distributions, correlations, or duplicates.
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 'Levels 0–1' implies this is a baseline check, but the description does not explicitly say when to use this tool versus alternatives like check_distributions or check_duplicates. There is no 'use this instead of X' guidance, leaving the agent to infer the intended context.
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. It discloses multiple behavioral traits: per-column outputs, flags for dedup/mojibake/HTML, a sample size cap on big data, and small output size. It doesn't explicitly state read-only/no side effects, but the analytical nature and output details give good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tightly packed paragraph that front-loads the purpose and then lists outputs and flags. Every sentence provides useful detail without excessive wordiness, though structure could be improved with bullet points.
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 the core analysis outputs, flags, and sample cap, and an output schema exists to define return structure. However, it lacks guidance on how to use the `columns` and `sample` parameters (e.g., what null columns means), leaving a gap for effective 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?
The description mentions 'Sample size cap on big data' which indirectly alludes to sampling, but does not explain the `sample` or `columns` parameters at all. With 0% schema description coverage, the agent receives no help interpreting these parameters from the description.
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 'Analyze' and resource 'text-heavy string columns' with a concrete threshold (avg length ≥ 20). It lists distinct output metrics (length distribution, vocab, near-duplicate %, content kind, mojibake) which clearly distinguish it from sibling check tools like check_distributions or check_duplicates.
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 clearly implies usage for text-heavy string columns, and the threshold condition (avg length ≥ 20) provides context. However, it doesn't explicitly compare with alternatives or state when not to use it, so it lacks exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well. It discloses that profiling uses a reservoir sample of max_rows rows, that suggested calls reference the original source_id, and that sample_info indicates what was sampled. It also notes output size is small. This provides meaningful behavioral context beyond typical assumptions.
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 efficiently structured: it opens with a clear purpose, then adds behavioral details in short, crisp sentences. No redundant wording, though it could be slightly shortened without losing value.
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?
The description covers purpose, internal logic, sampling behavior, and output characteristics. It references recommend_next for comparison and mentions sample_info. It does not explicitly explain how to choose between suggest_plots and recommend_next or other plotting tools, but this is a minor gap given the overall richness.
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 no descriptions for parameters (0% coverage), so the description must compensate. It clarifies max_rows (reservoir sample size) and hints (target/time columns), but max_suggestions is only named without explanation. source_id is self-explanatory. The description adds partial value but not complete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Recommend the most informative plots for a loaded source.' It specifies the resource (loaded source) and the action (recommend plots), and differentiates itself by referencing recommend_next and describing the internal inspection (column kinds, missingness, hints). This is a specific verb+resource+scope statement that distinguishes it from siblings.
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 by mentioning 'for a loaded source' and says it is 'similar to recommend_next,' but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or when-not-to-use guidance. The prerequisite (loaded source) is clear, but comparative guidance is absent.
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 disclosure burden. It reveals a key behavior: it filters findings without recomputing, suggesting a read-only operation. Yet it does not explicitly state side effects, error handling, or whether the original artifact is modified, leaving some 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 two sentences: the first states the purpose, the second documents the focus parameter. It is front-loaded, concise, and contains no 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?
The tool is simple (2 params, output schema present, no nested objects). The description covers the essential purpose and focus semantics. However, it does not compare with sibling tools like get_eda_findings or state prerequisites explicitly, leaving minor contextual gaps.
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 focus parameter is well explained with allowed values and its effect. run_id is implied as the identifier for the prior run_eda artifact, though not explicitly labeled. Given 0% schema coverage, this explanation partially compensates by adding meaning beyond the bare schema names.
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?
Clearly states the action (re-summarize) and the resource (prior run_eda artifact), with focus categories adding specificity. It distinguishes from run_eda by using 'prior', but it does not explicitly name sibling alternatives like get_eda_findings, so it is clear but not fully differentiated.
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?
Implies when to use it: after a prior run_eda artifact exists. The focus parameter (quality, bias, modeling, all) suggests intended use cases, and 'without recomputing' indicates a lightweight operation. However, there are no explicit when-not-to-use conditions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the resampling process, the computed metrics, the thresholds for flags, and notes that output size is small. It does not explicitly state that the operation is read-only, but it is implied as an analysis tool. The description adds meaningful behavioral context beyond a simple summary.
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, with a clear summary line followed by the key algorithm details. Every sentence adds value: it describes the process, the outputs, the thresholds, and the output size. No unnecessary content.
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?
The description covers the core algorithm, thresholds, and output size. With an output schema present, it does not need to detail return values. However, it lacks explicit guidance on when to use the tool compared to siblings, and could mention how it handles non-numeric or missing columns. Overall, it is complete for a moderately complex analysis 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 the description must compensate for the lack of parameter documentation. It explains 'n_bootstrap' by describing the resampling count and relates 'columns' to 'numeric column'. However, 'source_id' is not explained, and the description does not clarify the default behavior when 'columns' is null. This partial compensation merits a middle score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Bootstrap stability of column means + signal-to-noise ratio (Level 6).' It specifies the verb (bootstrap/compute), the resource (column means) and the key outputs (bootstrap_std, CV, SNR), distinguishing it from sibling check_* tools like check_distributions or check_correlations.
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 for detecting unstable column means via CV>0.1 and low signal via SNR<1, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. Usage is inferred from the tool's behavior rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing side effects. It states the action (fill nulls) and strategies, but it does not disclose whether the operation mutates the source in place, returns a new dataset, or how it handles invalid column names or missing strategies. This leaves the agent uncertain about the tool's behavioral profile; the description does not contradict any annotations, but it is incomplete for a mutation 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 front-loaded with the core action and then provides structured details on the mapping format. It is relatively concise, but the example spans multiple lines with awkward backtick placement, making the formatting slightly less clean. Overall, every sentence earns its place, but minor formatting quirks prevent a perfect score.
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 that the tool has three parameters, a nested mapping object, and no annotations, the description does a good job explaining the essential input structure. It covers the mapping strategies and an example, so the agent can invoke it. However, it lacks explicit guidance on when to use this tool versus alternative cleaning operations and does not mention side effects or prerequisites, which are important for a transformation tool. The presence of an output schema reduces the need to describe return values, but the description still leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions (coverage 0%), so the description is the sole source of meaning. It excellently explains the `mapping` parameter with a type template, a list of strategies, and a concrete example. The `source_id` and `alias` parameters are not explicitly described, but their purpose is self-evident from names and the schema, and the complex mapping parameter is fully covered, justifying a high score.
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 clear verb-phrase 'Fill nulls in named columns with a strategy,' naming the resource (columns) and the action (impute missing values). It also distinguishes itself from sibling clean_* tools by focusing specifically on imputation, and it explicitly defines the mapping structure and available strategies.
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 clearly implies the tool is for imputing missing values, and the mapping format is detailed. However, it does not explicitly state when to prefer this over other cleaning tools (e.g., clean_replace) or provide any exclusions such as column type requirements. The context is clear but lacks direct alternatives/contrasts, so it earns a 4 rather than a 5.
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 transparency burden. It discloses that it runs `run_eda deep` unless a `run_id` is supplied, stores full structured data in an artifact, and can double response size when sections are included. This provides meaningful insight into computational and output behaviors.
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 dense but well-structured, front-loading the core purpose in the first sentence and using bullet-style section lists to convey details efficiently. Every sentence contributes meaningful information without verbosity.
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?
The tool has moderate complexity and no annotations, but the description covers execution flow, output sections, artifact storage, and audience customization. It omits explicit details about `format` values and sibling differentiation, but these are minor given the richness of the rest of the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds semantic value to `source_id`, `run_id`, `audience`, and `include_sections` by explaining their roles and effects. However, `format` and `hints` are not elaborated, and with schema coverage at 0%, the partial compensation earns a mid-range score.
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 synthesizes a 'paste-ready brief' about `source_id`, with specific output sections. This distinct purpose sets it apart from sibling analysis tools like `describe_source` or `generate_report`, making it immediately actionable.
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 provides context for when to use `include_sections=True` (programmatic needs) and the `run_id` reuse option, but it does not explicitly compare against sibling tools or state when to prefer this over alternatives. Usage is implied rather than clearly delimited.
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. It discloses that output size is small and that sample rows are capped at the requested value (default 5), which is useful. However, it does not mention error conditions (e.g., what happens if source_id does not exist) or any other side effects, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and includes only essential operational details (output size, cap). Every sentence earns its place with no redundancy.
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?
The tool has a simple purpose and an output schema exists, so the description need not enumerate return fields. It covers the key aspects: what is returned, sample row cap, and output size. Minor gaps include lack of explicit prerequisites beyond 'loaded source' and no mention of error behavior, but given the output schema and simplicity, it is mostly complete.
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 explicitly explains 'sample_rows' by describing the cap and default value, which adds meaning beyond the schema. It does not explicitly name 'source_id', but the phrase 'loaded source' implies it; still, it could be more explicit about how source_id is used.
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 'Return' and clearly states the resource ('a loaded source') and the exact contents of the return (schema, sample rows, footprint). This distinguishes it from siblings like sample_rows or profile, which focus on subsets.
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 context that this is for loaded sources and returns descriptive metadata, which implies a use case. However, it does not explicitly contrast with alternatives like 'sample_rows' or 'profile', so it lacks explicit when-not-to-use guidance.
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 discloses truncation behavior (1500 chars) and result size, which is useful. However, it does not explain how metadata is detected, potential for recursive scanning, or that it only reads sidecar files.
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 concise sentences front-load the purpose and add a behavioral note. No redundant phrases.
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?
The tool is simple with one parameter and an output schema. The description covers purpose and output size, which is sufficient for an agent to invoke it, though it lacks explicit guidance on result format or edge cases.
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 description uses `path` to indicate the target location and specifies that scanning occurs 'in or alongside' it, adding context beyond the bare schema property. It suggests path can be a file or directory, which aids usage.
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 defines the tool's function with a specific verb ('Find') and resource ('sidecar metadata'), listing concrete examples (README, LICENSE, data dictionary, dataset card, manifest YAML/JSON). This differentiates it from sibling tools like list_files or detect_pattern.
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 to locate metadata files but does not explicitly state when to use it over alternatives like list_files or describe_source. No exclusions or alternative tool references 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 are provided, so the description carries the full burden. It adds useful behavioral details: 'Walk an ordered list' indicates the order matters, 'Output size: small' sets expectations. However, it does not explicitly state that the tool is read-only or explain what happens if the list is unordered. Moderate disclosure.
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 front-loaded with the main action. It uses a compact list for detected changes and includes a useful output-size note. No wasted words.
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 tool with one parameter and an output schema provided, the description covers the core purpose, detection types, and use case. It lacks explicit details on return structure, but the output schema fills that gap, making it sufficiently complete.
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 coverage is 0%, so the description must compensate. It adds the key semantic that source_ids must be 'ordered' and that they are walked sequentially. However, it does not define valid source_id formats or how ordering is determined, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Walk an ordered list of source_ids and report schema changes over time.' It also enumerates specific detection types (column added, column removed, type changed), making it distinct from sibling tools like detect_pattern or detect_metadata.
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?
Provides a clear use case: 'Useful for monitoring partitioned data (monthly parquets, API version snapshots) for breaking changes.' This gives context for when to use the tool, though it does not explicitly exclude alternatives or mention when not to use it.
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 disclosing side effects, and it does so by noting the tool is idempotent and output size is tiny. It also clarifies the side effect of freeing the DuckDB view, but it does not address error behavior or permissions. Overall, it adds useful behavioral context beyond the name and schema.
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. It front-loads the primary action and consequence, then adds two critical facts in terse fragments. No wasted words.
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 simple one-parameter tool, the description covers the core purpose, idempotency, and output size, and the output schema exists so return values need not be detailed. It stops short of mentioning how to find source IDs or what happens if the source doesn't exist, but these are minor gaps for such a focused 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?
The schema only defines source_id as a string with no description, and schema coverage is 0%. The description compensates somewhat by indicating the source is 'previously loaded,' which implies source_id must identify an existing source. However, it does not provide explicit details on how to obtain a valid source_id or its format, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Unregister') and resource ('a previously loaded source') and explains the consequence ('free its DuckDB view'). This distinguishes it from sibling tools like load_source (inverse) and list_sources (listing).
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?
Usage is implied: this tool is for unloading a previously loaded source. However, the description does not explicitly state when to use it versus alternatives, nor does it mention that list_sources can be used to find source IDs. No exclusions or alternative tools are named.
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 of behavioral disclosure. It goes beyond a generic statement by disclosing the plugin loading mechanism, the skip behavior based on `applies_to.has_columns`, and that each finding includes the plugin name in `evidence.plugin`. This provides meaningful insight into how the tool operates. It does not mention side effects or performance, but for a check tool the disclosed behavior is substantive.
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 three sentences, front-loaded with the main action in the first sentence. Each sentence adds distinct value: action, loading context, and output behavior. There is no fluff or redundancy, and the structure is easy to scan.
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 a single parameter, existence of an output schema, and the presence of many sibling check tools, the description is sufficiently complete. It explains the plugin source, the skipping logic, and the output format, which is enough for an agent to decide when to use it and what to expect. It could mention error handling or cost implications, but these are not critical for basic usage.
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 schema has 0% coverage and the description only references `source_id` as the target ('against `source_id`'). This adds minimal meaning beyond the parameter name itself. It does not explain what source_id represents, how to obtain it, or any constraints. For a single parameter with no schema description, the description should compensate, but it largely restates the parameter name.
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 a specific action: 'Run every loaded plugin (custom YAML+SQL check) against `source_id`.' It identifies the resource (plugins), the target (source_id), and the nature of the operation. It also differentiates from sibling check tools by specifying it is for custom plugins, not built-in checks.
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 context on when to use the tool: when you want to run all loaded custom plugins. It explains how plugins are sourced (plugins_builtin/ directory and --plugins), which implies this tool is for custom checks rather than built-in ones. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it stops short of a 5.
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. It discloses detection methods (by name or range), specific flags (out-of-range, Null Island, tiny-bbox), and output details (bbox, center, spread, distinct geographies). It does not explicitly state whether the tool is read-only, but the actions described (detect, validate, flag, report) imply non-mutating 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?
The description is concise, with the main purpose in the first line and supporting details following. It is well-structured and every sentence adds value. The use of bullet points in the second paragraph improves readability without being verbose.
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?
The description covers detection, validation checks, and reported outputs well. Since an output schema exists, return values are likely documented there. However, it omits explanation of the optional parameters and does not explicitly state usage scenarios, leaving some contextual 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. It mentions auto-detection but does not explain the optional lat_col and lon_col parameters, leaving their purpose ambiguous. The description could have clarified that these allow overriding the auto-detection, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Auto-detect lat/lon columns and validate ranges.' It specifies the resource (geospatial data) and the specific actions (detect, validate, flag, report). This distinguishes it from sibling tools like check_outliers or check_temporal, which have different focus areas.
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 implies usage for geospatial data quality validation by mentioning detection, range checking, and spatial reports. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure and does so excellently. It specifies concrete thresholds (VIF>10 problematic, VIF>5 moderate, |r|≥0.8 for grouping), states that ID-like unique columns are skipped, caps at 50 numeric columns, and notes 'Output size: small'. These details go far beyond generic expectations and set clear behavioral expectations.
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. The first line states the core function in a compact summary, followed by bullet-like details that are easy to parse. Every sentence adds value without wasted words, and key constraints are front-loaded.
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 check tool, the description covers the essential behavior, thresholds, limits, and output size. An output schema is present, so return values are presumably documented elsewhere. The main missing piece is the interaction with the columns parameter, which would clarify whether the analysis applies to all numeric columns or only those selected. This is a minor gap given the overall richness.
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 schema has two parameters (source_id and columns) with 0% schema description coverage, so the description must compensate. However, the description never explains what these parameters are or how to use them. While it mentions 'columns' behaviorally (e.g., 'Caps at 50 numeric columns'), it does not clarify that the columns parameter restricts the analysis to selected columns or what happens when it's null. This leaves a significant gap for an agent selecting and invoking the tool.
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 explicitly states the tool performs Variance Inflation Factor (VIF) and correlated-group detection, which is a specific verb+resource combination. It distinguishes itself from sibling tools like check_correlations by focusing on multicollinearity and providing detailed behaviors (VIF thresholds, grouping at |r|≥0.8). This makes the tool's purpose unmistakable.
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 usage context is implied through the description (e.g., multicollinearity detection for regression modeling) but no explicit comparison to alternatives is given. It does not say when to prefer this tool over check_correlations or other check tools, nor when not to use it. The phrase 'Level 3' is cryptic and provides no actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It fully explains the methods, the output (counts, sample extreme values, row indices per method), the verbose flag's effect on response size, and the artifact behavior. This goes beyond basic transparency and covers the tool's operational nuances extensively.
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 two paragraphs, but every sentence adds value: method list, output summary, diagnostic note, verbose behavior, and artifact. It is front-loaded with the core purpose and maintains a logical flow. Slightly dense but appropriately sized for the tool's complexity.
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?
The description covers the tool's purpose, methods, output, and verbosity behavior, but omits details on the `columns` and `max_per_method` parameters and their interplay with default behavior. Given the existence of an output schema, return values are partially explained, but the parameter gaps keep it from being fully complete. Still, it provides substantial context for a complex 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%, so the description must compensate. It thoroughly explains `verbose` but leaves `columns`, `source_id`, and `max_per_method` without explicit semantic context. The `top_findings` mention indirectly relates to limits but does not clearly map to `max_per_method`. The description falls short of documenting all parameters given the lack of schema-level descriptions.
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 starts with a specific verb+resource: 'Detect outliers in numeric columns using three methods side-by-side.' It names the exact methods (z-score, IQR, modified z-score) which clearly distinguishes it from sibling tools like check_quality or check_distributions. The purpose is unambiguous and detailed.
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 clearly indicates the tool is for outlier detection in numeric columns and even hints at how to interpret disagreements ('Disagreement between methods is itself diagnostic'). It does not explicitly name alternative tools or provide exclusion criteria, but the context is strong enough for an agent to decide when to use it. It lacks explicit when-not-to-use guidance.
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 adds valuable context: sampling N rows per column (default 5000), returns redacted examples, never raw values, and output size is small. It does not explain the 'strict' parameter or how 'columns' filters, but the key safety behavior (redaction) 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 four concise sentences, front-loaded with the main purpose and followed by bullet-like pattern list and key behavioral notes. Every sentence adds value, with no repetition of the input schema or fluff.
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 has 4 parameters, no annotations, and an output schema that likely describes return values. The description covers the core behavior (PII detection, sampling, redaction, output size) but omits explanations for 'strict' and 'columns.' While output schema reduces the need to describe return format, the missing parameter semantics leave the description incomplete for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'sample' parameter (default 5000) and indirectly hints at 'columns' through 'column-name heuristics,' but it does not clarify 'strict' or 'source_id.' The addition is helpful but incomplete for a 4-parameter tool with no schema descriptions.
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 'Detect PII via regex + column-name heuristics,' using a specific verb and resource that clearly distinguishes it from sibling tools like check_quality or detect_pattern. It further lists concrete patterns (email, phone, SSN, credit-card, etc.), making the purpose unmistakable.
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 clearly implies when to use the tool: when you need to check a dataset for PII. It provides context by listing the types of PII and the sampling behavior, but does not explicitly mention alternatives or exclusions. This is clear context without formal when-not-to-use guidance.
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 behavioral disclosure burden. It states the output size ('small') and the precise detection criteria, indicating a read-only sanity check. It does not explicitly rule out side effects, but the nature of the tool makes that implicit.
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 front-loaded with the tool's purpose and follows with a compact bullet-style list of detections. It is appropriately sized and avoids 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?
The tool is moderately complex with three parameters and an output schema. The description covers detection behavior and output size, and the output schema can define return values. The meaning of 'Level 4' is left unexplained and source_id is underdescribed, but overall it's adequate.
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 coverage is 0%, so the description must explain parameters. It explains time_column by specifying DATE/TIMESTAMP and mentions value_columns implicitly via 'per numeric column'. However, source_id is not described at all, leaving a semantic gap.
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 tool as performing time-series sanity checks with a specific list of detections (gaps, monotonicity, sampling frequency, drift, seasonality). This distinguishes it from sibling check_* tools, which are general or target different data types. The verb 'Detects' makes the action explicit.
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 specifies a prerequisite (requires time_column of type DATE/TIMESTAMP) and implies it's for time-series data. However, it does not explicitly compare to alternatives like check_stability or plot_timeseries, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the heuristic-driven method, the inputs it scans (column types and shapes), and the detailed output structure (target candidate, predictor list, feasibility, challenges, first step). This is notably 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 two sentences, front-loaded with the core purpose, followed by a concise, structured breakdown of the heuristic approach and output components. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single self-evident parameter and presence of an output schema, the description is largely sufficient, covering method, scope, and result format. It could mention prerequisites like whether the source must be loaded, but this is a minor gap.
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 schema has zero description coverage and the tool description does not explicitly explain the source_id parameter. Although the name is self-explanatory, the description should compensate for the lack of schema documentation, and it does not.
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 ('Propose') and resource ('ML / analytical tasks the data is well-suited for'), and enumerates concrete task types (classification, regression, etc.), making it clearly distinct from sibling tools like suggest_plots or infer_recipes.
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 (when you want ML/analytical task suggestions based on data shape) but provides no explicit guidance on when not to use it or how it compares to alternatives such as infer_recipes or auto_explore.
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. It discloses the exact statistical methods (Pearson/Spearman, ANOVA/η², χ²/Cramér's V, Welch t-test/Cohen's d) and the output format (ranked features with effect sizes and strength buckets). This goes beyond a generic statement and provides meaningful behavioral insight, though it does not cover edge cases or potential 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 concise and front-loaded with the main purpose. The subsequent sentences efficiently list the type-pair test selection and output summary, with no redundant or filler content. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description adequately covers the methodology and return values. It mentions pairing with auto_modeling_audit and explains the strength buckets. The only gap is the lack of explicit source_id description and potential edge cases, but overall it is sufficient for an experienced user.
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 explicitly defines target_column as the column relative to which features are scored. source_id is not mentioned, but its name strongly implies the dataset identifier. With only two parameters and one clearly explained, the description provides partial compensation but not full clarity for both.
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 'Score every feature for signal strength relative to target_column,' which clearly identifies the action (scoring features), the resource (features), and the target. It distinguishes itself from sibling tools by detailing specific statistical tests for each type pair, making it unique among check_* 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 provides clear context for when to use this tool (e.g., to score feature signal against a target) and mentions it pairs with auto_modeling_audit. However, it does not explicitly state when not to use it or name alternative tools like check_correlations or check_multicollinearity, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It details the detection logic, conditional operation on target/time, and states output size is small. It does not explicitly mention side effects, but read-only nature is implied by 'check'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement and three enumerated layers, each earning its place. It is detailed but not verbose, with no superfluous content.
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?
The description covers all three detection layers, parameter conditioning, and output size. It does not explain return structure, but an output schema exists, so that is not required. It could mention prerequisites or limitations, but overall it provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the role of target_column and time_column by tying them to detection layers, but does not describe source_id or expected value formats, leaving significant gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs three-layer leakage detection, specifying concrete detection mechanisms (name heuristics, correlation >0.95, temporal consistency). This distinguishes it from sibling check tools like check_correlations or check_temporal.
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 explains when each detection layer applies based on provided parameters: Layer 1 always, Layer 2 when target is provided, Layer 3 when target and time are provided. This gives clear context for parameter usage, though it does not explicitly name alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses a key behavior: non-castable values become NULL instead of erroring. It also notes the output is a new source. It does not mention potential side effects like permission requirements or whether the original source is modified, but 'new source' implies immutability.
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 three sentences: purpose, behavior, and common casts. Each sentence adds value and is front-loaded, with no redundant or vague wording.
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?
The tool has a moderate complexity with an output schema and nested objects. The description covers the main functionality, the NULL behavior, and usable dtype examples. It lacks a brief note on the 'alias' parameter and how to specify multiple columns in the mapping, but overall it is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the core 'mapping' parameter by stating columns are cast per mapping and lists common dtype strings. However, it does not clarify the optional 'alias' parameter or the exact structure of the mapping keys, leaving some ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool casts columns to new data types using TRY_CAST, creating a new source. It is specific about the verb (TRY_CAST) and the resource (columns to dtypes), distinguishing it from sibling cleaning tools like clean_drop_columns or clean_filter.
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 context that this is appropriate for type-drift workflows where a few outliers are acceptable. It implicitly advises against use when errors should be surfaced, but it does not explicitly name alternative tools or state when not to use it.
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 burden and does well by disclosing that the original is preserved, the new source is auto-named, and the return includes deltas and a replayable Recipe. It does not cover edge cases like missing columns, but the key behavioral traits are 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 compact and front-loaded: the first sentence states the core behavior, and the second details return values. Every sentence earns its place without redundant 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?
The description is reasonably complete for a moderate-complexity transformation tool: it covers the non-destructive behavior, naming scheme, and return values. Given an output schema exists, this is sufficient, though it could add details on error handling or column existence checks.
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 coverage is 0%, so the description must compensate. It explains that `columns` are the named columns to drop and clarifies the `alias` behavior (auto-naming `{source}_v{N}` unless alias is given). This adds meaningful semantics beyond the bare 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 clearly states the tool's function: it drops named columns and creates a new source, distinct from siblings like clean_drop_duplicates and clean_rename. It also specifies the non-destructive nature ('Original is preserved') and the result type.
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?
Usage is implied rather than explicitly stated—the tool is for dropping columns, and preserving the original offers context. However, it does not name alternative tools or provide when-not-to-use guidance, so the agent must infer the right context from the purpose.
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 transparency burden. It discloses that a new source is produced (implying non-destructive), the default drop behavior, and the `keep=True` switch. It includes DuckDB-specific syntax details. It does not cover edge cases or the purpose of `alias`, but the core behavior is well communicated.
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 compact and well-structured: it leads with the purpose, then gives concrete `where_sql` examples and parameter defaults. No filler words; every sentence adds value.
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?
The description covers the essential behavior, syntax, and default semantics, which is sufficient for a tool of moderate complexity. The existence of an output schema means return values need not be explained. The only notable omission is the `alias` parameter, but overall it is adequate.
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%, placing the burden on the description. It thoroughly explains `where_sql` with examples and the `keep` default. `source_id` is implied as the input, but `alias` is not mentioned at all. Thus the description compensates for the most important parameters but leaves a gap for `alias`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new source by dropping (default) or keeping rows that match a `where_sql` expression. This specific verb+resource pairing distinguishes it from sibling clean_* tools like clean_drop_duplicates or clean_drop_columns, which target duplicates or columns rather than arbitrary row filters.
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, including exact `where_sql` syntax, examples, and the effect of the `keep` parameter. However, it does not explicitly mention alternative tools or when not to use this tool, so it stops short of full guidance.
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 full burden. It discloses the key behavioral detail that JSON null maps to SQL NULL, and implies a new source is created rather than modifying the input. However, it does not specify behavior for unmapped values or case sensitivity.
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, front-loaded with the core purpose, and uses a clear example to illustrate null mapping. Every sentence adds value without any fluff.
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?
The tool is relatively simple and an output schema exists, so return values do not need explanation. The description covers the main purpose and the important NULL mapping behavior, but could optionally mention how unmapped values are handled. Overall, it is sufficiently complete for a data cleaning operation.
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 coverage is 0%, so the description must compensate. It adds meaningful semantics for the 'mapping' parameter with an example and explains null mapping. However, source_id, column, and alias are not explained beyond their names, leaving some parameter semantics to inference.
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 that it creates a new source with column values replaced per mapping, which is a specific verb+resource+operation. This distinguishes it from sibling clean_* tools like clean_filter or clean_impute by specifying the exact transformation (value replacement).
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 a clear use case: removing sentinel values like 'NA' or -999 by mapping them to SQL NULL. This implies when to use the tool, but it does not explicitly mention when not to use it or name alternative tools. Still, 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?
The description explicitly discloses the in-place mutation trait and gives exact formulas for each transform, which is good. However, with no annotations, it omits other important behavioral details such as reversibility, what happens to nulls, or whether the operation is destructive. The 'in place' phrasing helps but is a minimal disclosure for a mutation 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 tight and efficient: one main sentence followed by a focused bullet list. Every line adds value, and the key information is front-loaded. No fluff or repetition.
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?
The transformation semantics are well-covered, and the existence of an output schema means return values are handled externally. Missing is any explanation of the alias parameter or caveats about in-place mutation (e.g., irreversibility). Overall, it covers the most complex aspect thoroughly but leaves a couple of secondary aspects unclear.
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 mapping parameter is exceptionally well explained, with each allowed string value accompanied by a formula and use case, adding significant meaning beyond the bare schema (which only says additionalProperties with string values). However, the alias parameter is not mentioned at all, and with 0% schema coverage, this leaves a gap. Still, the core parameter receives thorough treatment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies mathematical transforms to numeric columns in place, with a specific verb and resource. It also enumerates the transform kinds (log1p, sqrt, z_score, min_max), sharply distinguishing it from sibling cleaning tools like clean_drop_columns or clean_impute.
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 context for when to use each transform (e.g., 'log1p... handles zeros, common for skewed counts', 'z_score... zero-mean, unit-variance'), enabling an agent to select the appropriate kind. It does not explicitly mention alternatives or when not to use, but the purpose context is strong enough for most decision-making.
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: it discloses that the operation reads cached JSON with no recomputation, is cheap, and output size scales with limit. It also explains filter composition and severity values, which goes beyond basic 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?
The description is compact and well-structured, with each line adding substantive information: what it fetches, how filters combine, severity values, paging, cost behavior, and output size. No redundant or filler content.
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?
The description covers purpose, usage context, behavioral characteristics, filtering, and paging. With an output schema present, return values are already accounted for. Minor gaps remain: no explicit comparison to alternatives and some parameter semantics (column/category) are not fully addressed, but overall it is sufficient for an agent to select and invoke confidently.
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 for parameter meanings. It explains severity values, offset/limit for paging, and run_id context, but does not clarify the semantics of 'column' and 'category' filters. Some parameters remain underspecified.
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 the specific verb 'Fetch' with the resource 'findings from a prior run_eda artifact', clearly distinguishing this as a retrieval tool for prior EDA results. It further specifies 'filtered, paginated view', which precisely defines its function among siblings like run_eda or summarize_run.
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 states the tool operates on 'a prior run_eda artifact', indicating it should be used after running run_eda. It also provides cost guidance ('Cheap — reads cached JSON, no recomputation') and pagination usage ('Use offset/limit to page through'), but does not explicitly name alternatives or when-not-to-use conditions.
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. It discloses format auto-detection, format override, glob/directory unioning with schema constraints, the return payload (id, format, schema, row count, etc.), and output size. It does not mention permission requirements or overwrite/alias conflict behavior, but the major behaviors are well-covered.
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 front-loaded with the primary action. The format list, glob/directory note, return field list, and output size line are all useful and add no fluff. Every sentence contributes to understanding the tool.
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?
This is a complex tool with four parameters, multiple formats, and glob/directory behavior. The description covers the core functionality, edge cases (schema matching for unions), return fields, and output size. Missing alias and options semantics, but the provided output schema and structured return info help fill some gaps. Overall, it is quite complete for an agent to decide and invoke.
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 explain the format parameter ('pass format= to override') and path semantics (globs/directories unioning), but it does not explain the alias or options parameters. This partial coverage is better than nothing but leaves two of four parameters opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a CSV/TSV/Parquet/JSON/NDJSON file, glob, or directory and registers it as a queryable source. This verb+resource+scope is specific and distinguishes it from siblings like list_sources (which lists existing sources) and unload_source (which removes a source).
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 context: use this when you want to load and register a source for querying. It implicitly contrasts with list_files (which likely just lists files) and describes glob/directory unioning behavior. However, it does not explicitly name alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that passing source_id runs quick EDA if no run is cached, run_id reads from artifact, and return values come with full args ready to invoke. This adds meaningful context beyond what a schema or annotations would provide.
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 compact, front-loaded with the key outcome, and uses formatting (bold, code) to emphasize important terms. Every sentence adds value with no redundancies.
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?
The tool has an output schema, so return structure need not be fully described. The description covers input alternatives and a key behavioral trait (pre-filled args). Given the moderate complexity and the presence of many sibling tools, it is sufficiently complete for an agent to decide 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.
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 clarify parameters. It explains source_id and run_id semantics, but does not explain `hints`. This partial compensation is adequate but leaves one 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 clearly states the tool's purpose: 'Return ranked, pre-filled next-action tool calls.' It uses a specific verb (Return) and resource (next-action tool calls), and the 'pre-filled' detail distinguishes it from sibling tools like recommend_tasks.
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 by explaining when to pass source_id versus run_id, and notes it is designed for local models picking from a numbered menu. It doesn't explicitly exclude alternatives, but the parameter guidance is actionable and implies when this tool is appropriate.
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. It discloses that near=True is a placeholder (not functional), which is critical to avoid misuse. It also explains the behavior with keys (duplicate groups) and gives output size. It does not mention permissions or read-only nature, but 'check' implies read-only; still, the placeholder disclosure adds significant value.
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 three short sentences, front-loaded with the core purpose. Every sentence adds value: the first states the exact detection scope, the second explains behavior with keys, and the third clarifies the near placeholder and output size. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, output schema present), the description covers the essential behavior: what it detects, parameter effects, and output size. It doesn't mention prerequisites like having a loaded source, but that's implied by source_id. It also doesn't mention return format, but the output schema covers that. Slightly incomplete regarding edge cases or error conditions, but otherwise solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists parameter names with no descriptions (0% coverage). The description compensates by explaining 'keys' (duplicate groups under those keys) and 'near' (placeholder for Phase 3 fuzzy matching). This adds meaning beyond the schema, particularly for near, which could otherwise be misinterpreted as functional fuzzy matching.
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 'Exact duplicate detection (Level 2)' which clearly specifies the tool's purpose and scope. It further distinguishes from fuzzy matching by noting near=True is a placeholder, making it clear that this tool is for exact duplicates only. This separates it from sibling tools like clean_drop_duplicates or check_quality.
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 for exact duplicate detection, especially when fuzzy matching is not yet available (near=True is a placeholder). However, it does not explicitly state when to use this tool over alternatives like clean_drop_duplicates or check_quality, nor does it mention any exclusions. The 'Output size: small' hint is useful but not a full guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It thoroughly explains the walk over nested STRUCT/LIST schema, the exact rows/fields inspected, the 80% presence threshold, the DuckDB JSON fallback meaning type drift, and the returned SQL. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three compact, well-structured sentences. The first sentence states purpose, the second enumerates output details, and the third explains flags and return value. There is no redundancy 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?
With an output schema and only two parameters, the description covers purpose, outputs, thresholds, and type-drift interpretation thoroughly. The only notable gap is the undocumented sample parameter, preventing a perfect score.
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 source_id or sample. While source_id is inferable from the name, sample (the number of rows to inspect) is completely undocumented, so the description fails to compensate for the lack of parameter documentation.
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 action ('walk the nested STRUCT/LIST schema' for JSON-loaded sources) and names concrete outputs: leaf-path type, presence percentage, type-drift/sparse flags, and a paste-ready flatten SQL. It clearly distinguishes itself from generic tools like describe_source or check_arrays.
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 opening 'For JSON-loaded sources' provides a clear context for when to use this tool. It does not explicitly name alternative tools or when not to use it, but the intended scope is evident. This is 'clear context, no exclusions' rather than a full alternatives comparison.
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. It implies a non-mutating computation by using 'compute' and 'stable hash', and adds behavioral details like 'loaded source' and 'Output size: tiny'. However, it does not explicitly state side-effect absence or error conditions, but the nature of hashing makes the read-only behavior 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 two sentences, front-loaded with the core action. Every sentence earns its place: compute action, usage guidance, and output size. There is zero waste and excellent structure.
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?
This is a simple single-parameter tool with an output schema present. The description explains the purpose, usage scenario, and output size, which is sufficient given the tool's complexity. It also places the tool in a workflow (avoiding re-running EDA), making it contextually complete.
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 only source_id with no description, and schema_description_coverage is 0%. The description adds that the tool works 'for a loaded source', which gives context to the parameter, but it does not explicitly define source_id or its constraints. This partial compensation is adequate 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 clearly states the tool computes a stable hash of schema and content sniff for a loaded source. This specific verb+resource combination distinguishes it from siblings like describe_source or check_stability. The purpose is unambiguous and immediately understandable.
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 a clear use case: detecting dataset changes across MCP sessions without re-running EDA. It gives practical context but does not explicitly mention alternative tools or when not to use it, so it misses the 'when-not' or alternatives that would earn a 5.
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 burden of disclosing behavior. It adds useful context: output size small (<2KB typical), no arguments, and cheap. This goes beyond a simple restatement of 'list' and helps set expectations, though it does not explicitly confirm side-effect-free 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?
The description is extremely concise: one main sentence followed by a short behavioral note. Every word earns its place, and the most critical information is front-loaded. There is no padding or redundancy.
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 zero-parameter tool with an output schema, the description provides sufficient context: what it lists, output size expectation, and cost. No return value explanation is needed given the output schema exists. It fully covers the necessary information in a simple, well-scoped 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?
The tool has zero parameters, and the input schema is empty (100% coverage). The description adds the explicit statement 'No arguments,' which reinforces the schema and is helpful for an agent deciding whether to invoke with parameters. Baseline for 0 params is 4.
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 'List every data source currently loaded in this MCP session' with a specific verb and resource. This distinguishes it from sibling tools like describe_source or load_source, which have 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 usage for a quick overview of loaded sources by mentioning 'No arguments. Cheap.' but does not explicitly state when to use this tool versus alternatives like describe_source or compare_sources. There are no exclusions or alternative tool references.
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 burden. It discloses that class-balance and chi-square always run regardless of parameters, that disparate impact only runs when both optional params are supplied, and notes the output size is small. This is useful behavioral context beyond a simple summary.
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?
Three sentences with no fluff. The opening line summarizes the three checks, then the following sentences give precise conditions and output size. Every line adds value.
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?
The tool has an output schema, so return format details are not needed. The description covers what checks run, when they run, and the output size. It omits error conditions or data type prerequisites, but for a 3-parameter check tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the role of outcome_column and protected_attributes in triggering disparate impact, and implicitly defines source_id as the data source. The '2-20 cardinality cats' detail adds context for the class-balance check.
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 defines the tool as running three bias checks: class imbalance, sampling bias, and conditional disparate impact. It names specific statistical methods (chi-square, 80% rule) and distinguishes from siblings by focusing specifically on bias rather than general quality or distribution checks.
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 states that class-balance and sampling bias always run, while disparate impact requires both outcome_column and protected_attributes. This gives clear conditional guidance, though it doesn't explicitly contrast with alternative check_* tools. The conditions imply when the tool is relevant.
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. It discloses the statistical methodology (t-test/Mann-Whitney, ANOVA/Kruskal-Wallis), effect sizes, CI, and return value structure. However, it omits assumptions like numeric metric or missing data handling.
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 compact, front-loaded with the core purpose, and follows with terse bullet-like specifications. No redundant sentences.
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?
The description covers the tool's decision logic and output components, and an output schema exists. It doesn't mention data prerequisites or handling of edge cases, but given the output schema and sibling context, it is adequately complete.
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 clarify parameters. It explains the roles of `metric_column` and `group_column` via the comparison logic, but doesn't explicitly describe `source_id`. This adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs statistical comparison of a metric column across group levels, with specific test selection for 2 vs >2 groups. This distinguishes it from sibling tools like compare_sources or auto_compare, which focus on different comparison targets.
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?
Provides clear context for when to use this tool (comparing a metric across groups) and specifies conditions within the tool (2 vs >2 groups). However, it doesn't explicitly name alternatives or exclusions relative to sibling tools like auto_compare or compare_sources.
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 burden. It discloses important behaviors such as auto-sampling sources over 500K rows, returning a verdict, and the specific statistical tests used. It does not explicitly mention read-only behavior or side effects, but the analysis nature is implied.
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 compact and informative, with each sentence delivering a distinct fact: purpose, verdict, numeric methods, categorical methods, auto-sampling, and optional parameter. No wasted words.
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 moderately complex analysis tool, the description covers the core behaviors: the comparison scope, statistical tests, sampling strategy, and optional key-based overlap. With an output schema present, the lack of return-value details is acceptable. It could be more explicit about prerequisites or when to use alternatives, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions, but the description explains that source_a and source_b are the two sources being compared and that `keys` enables join-key overlap stats. This adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs schema diff and per-column distribution drift between two loaded sources, with specific outputs (drop-in verdict) and statistical methods (PSI, KS, chi-square). This distinguishes it from sibling tools like check_distributions (single source) and auto_compare.
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 implies usage for comparing two already-loaded sources and advises passing `keys` for join-key overlap stats. However, it does not explicitly state when to prefer this over alternatives like auto_compare or compare_groups, nor give exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It specifies recognized pattern types, the return format (a suggested load_source call), and an output size cap (file lists capped at 50). It does not mention permissions or failure modes, but for a read-only scanning tool this is adequate and goes beyond a vague description.
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 efficient and front-loaded, leading with the core purpose. The list of patterns and output cap adds valuable detail without unnecessary verbosity. It could be slightly tighter, but every sentence earns its place.
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 tool with one parameter and an output schema, the description covers the input type and output behavior adequately. It mentions output size and actionable return value, and while it could note error handling or read-only guarantees, the combination of description and output schema makes it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'path' parameter with 0% description coverage, so the description must compensate. It does so by explicitly stating that the path can be a directory or a single file, and the list of recognized patterns gives further context about what the parameter should point to.
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 action ('Scan a directory (or single file) and identify its multi-file structure') and enumerates concrete recognized patterns (e.g., partitioned_parquet, mysql_dump). This clearly distinguishes it from sibling tools like list_files or describe_source, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: run this tool to understand a dataset's multi-file structure before calling load_source. It even provides the workflow by returning suggested load_source(args). However, it does not explicitly name alternative tools or state when not to use it, so it falls short of full differentiation.
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. It discloses the output form ('ready-to-paste loader code'), target semantics ('all' vs single flavor), and output size ('small'), which are the key behavioral traits of this code generator. It could add prerequisites (e.g., source must exist), but it does not hide side effects or mislead.
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?
Three sentences, each provides distinct information: the main action, target usage/behavior, and output size. No filler, repetition, or unnecessary detail. The structure front-loads the core purpose and keeps the details compact.
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 small code-generation tool with an output schema, the description covers the main action, language flavors, target behavior, and output footprint. It does not explicitly explain how to obtain source_id (e.g., via list_sources), but that is a common cross-tool dependency and does not leave a critical gap for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions, so the description must compensate. It adds real value for target by explaining the 'all' behavior and the accepted single values. source_id is only implied as 'the source' from the opening sentence, but the parameter name and overall context make it understandable.
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?
Description opens with a specific verb ('Generate') and resource ('ready-to-paste loader code'), enumerates four language flavors (Python/DuckDB, Polars, Pandas, SQL), and differentiates itself from siblings like load_source by noting it lets users reproduce loading without the MCP. This is a precise action on a clear deliverable.
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 states the primary use case ('reproduce loading without the MCP') and explains how to select flavors with target. It does not explicitly name alternative tools or state exclusions, but the context clearly signals that this is for generating external code rather than performing an in-session load.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses server-side binning for numeric columns, top-50 value counts for categorical columns, the return format (structured JSON + inline PNG as MCP ImageContent), and the reliability benefit of single-image responses. This is rich, useful behavior information beyond what any schema could convey.
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 tightly written: three sentences, each earning its place. The first sentence front-loads the core purpose, the second details behavioral nuances, and the third provides client-compatibility guidance. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (multiple plot types, output format) and the absence of an output schema or annotations, the description covers the essential points: what it does, how numeric vs. categorical columns are handled, what the return includes, and when to prefer it over an alternative. It lacks some edge-case details (e.g., behavior for mixed columns), but it is sufficiently complete for most agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'columns' can be a single column or multiple, and it touches on binning behavior which relates to the 'bins' parameter, but it does not explicitly describe the 'bins' parameter's effect or the meaning of 'source_id'. The description adds some meaning but leaves gaps for two of the three 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 opens with a crisp, specific purpose: "The right tool to answer 'show me the distribution of X'" and explains the single-column vs. multi-column behavior. It also distinguishes itself from a sibling by explicitly naming eda_storyboard as the alternative for focused per-column questions. This clearly states the tool's unique role.
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 explicit guidance on when to use this tool: for focused per-column distribution questions, and even directs users to prefer it over eda_storyboard. It implies broader explorations would use eda_storyboard, but it doesn't explicitly state all exclusions or other alternatives, so it falls just short of full when/when-not coverage.
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. It discloses important behaviors: 'Read-only by default,' row cap ('Rows are capped at `limit` (default 100)'), return format ('Returns rows + schema + a `truncated` flag'), and output size ('scales with limit; default ~10–50KB'). This goes beyond minimal but lacks some details like error handling or possibility of overriding read-only, preventing a 5.
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 four sentences, front-loaded with the primary purpose. Each sentence adds necessary information: purpose, cross-source capability, limit/return behavior, and output size. No fluff or repetition, making it highly efficient.
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 tool with no annotations and an output schema, the description covers the essential aspects: what it does, read-only behavior, limit handling, and output structure. It omits potential concerns like timeout/error behavior or exact schema of returned rows, but the presence of an output schema reduces the need to detail return values. It is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains `limit` as a row cap with a default of 100, and `sql` is implicitly defined by the purpose ('Run arbitrary SQL'). The description adds performance context ('Output size: scales with limit'), which is valuable. It does not fully detail SQL syntax or edge cases, but it adequately covers the two 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 clearly states the function: 'Run arbitrary SQL against the session's DuckDB connection.' It specifies the verb (run), the resource (SQL on DuckDB connection), and the scope (arbitrary), distinguishing it from sibling tools that are targeted for specific analyses. The mention of cross-source JOINs further clarifies its unique capability.
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 context for when to use the tool: when arbitrary SQL is needed, especially for cross-source JOINs. It states 'Cross-source JOINs work because every loaded source is a view in the same connection,' which implies a key use case. However, it does not explicitly exclude alternative tools or provide when-not guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden and discloses mode constraints ('stratified' requires stratify_by), default column behavior, and output size scaling with n × columns. It stops short of explicitly stating read-only semantics, but 'pull a sample' implies a non-mutating 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 four sentences, front-loaded with purpose, and each sentence adds value: purpose, modes, columns usage, and output size estimate. There is no fluff or repetition.
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?
The description covers the tool's purpose, all five parameters, behavioral constraints, and output size, and an output schema is present, so return values needn't be described. It is complete for a sampling tool, with minor gaps like explicit edge cases.
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%, and the description compensates by explaining the mode enum values, the columns projection purpose, the stratify_by requirement, and n's role in output size. It could explicitly define n as row count, but it is inferable from context.
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 'Pull a sample from a loaded source,' clearly stating the verb and resource, and lists the supported modes (random, head, tail, stratified), which differentiates it from sibling tools like describe_source or run_sql.
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 explains when to use the columns parameter ('useful on wide sources (20+ cols)') and describes each mode, giving context for choosing sampling options. It does not explicitly name alternative tools, but the context is clear enough for an agent to decide when sampling is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers: sequential op execution, default alias behavior, materialization into a real DuckDB TABLE, and the trade-off of disabling it. This is rich behavioral disclosure beyond the basic 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?
The description is information-dense and well-structured, covering purpose, ops format, and materialization trade-off in a compact paragraph. No wasted words, though slightly longer than minimal.
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 tool with 4 parameters and no annotations, the description is remarkably complete: operation semantics, parameter formats, defaults, and side effects are all addressed. The existing output schema covers return values, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description explains the critical `ops` structure (list of kind/args dicts), `alias` default, and `materialize` behavior. `source_id` is self-evident from context, so all meaningful semantics are covered.
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 'Apply a sequence of cleaning ops in order' and 'Returns one new source', providing a specific verb and resource. It implicitly distinguishes itself from single-op cleaning tools by emphasizing sequential application, but does not explicitly name alternatives like auto_clean or clean_drop_duplicates.
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: ops run sequentially, and materialization is recommended for heavy downstream use vs short-lived exploratory cleanups. However, it does not explicitly state when to prefer this tool over alternative cleaning tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels. It explicitly states 'Plan-only — does NOT modify data,' and details the return format (Markdown plan + structured ops list) and the auto-mapping logic, making behavioral expectations 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 well-structured and front-loaded with the core purpose. It uses concise bullet-style lines for the auto-mapping rules, avoiding unnecessary fluff while delivering key information efficiently.
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 the tool has only one parameter and an output schema exists (which covers return structure), the description covers all essential aspects: purpose, side effects, output format, and follow-up actions. It is complete and self-contained for the tool's complexity.
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 coverage is 0% and the description does not mention the 'source_id' parameter at all. The name is self-explanatory to some degree, but the description provides no additional context or constraints, leaving the agent to guess what a valid source_id looks like.
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 'Inspect quality + duplicate findings and PROPOSE a cleaning plan,' which is a specific verb+resource combination. It clearly distinguishes itself from execution tools like clean_pipeline by emphasizing 'Plan-only — does NOT modify data.' The auto-mapping rules further clarify its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: for proposing a cleaning plan, and directs the caller to pass the ops to 'clean_pipeline' for execution. It also clearly indicates what it does NOT do (does NOT modify data), providing a clear when-not scenario and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It reveals downsampling via reservoir sampling, performance caveats on 7M+ rows, convergence at ~500K rows, and that the sample is surfaced in sample_info. This is substantial added 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 compact yet rich: a hook, a clear core statement, and two sentences of behavioral guidance. Every sentence earns its place with no fluff.
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?
The description covers purpose, verdicts, sampling behavior, and output field, and an output schema exists. It is complete for the tool's complexity, with no critical gaps.
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 description must compensate. It provides detailed guidance on max_rows, explaining its role in downsampling and how to adjust for a full pass. Other parameters are self-explanatory or hinted (time_column for temporal), making this adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: assessing model-readiness by chaining multiple checks into a ranked-blocker brief with a verdict. It uses a specific verb ('Chains') and names exact checks, distinguishing it from sibling check_* 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 opening question 'Can I train a model on this without footguns?' provides clear context for when to use the tool. It implies it is the holistic model-readiness audit, but does not explicitly mention alternatives or exclusions, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses aggregation logic, report details (shape, dtype, NaN/Inf %, range), flag thresholds (NaN/Inf >1%), fill values, cap_hit behavior, n_groups_total vs n_groups_walked, and output size scaling. This is exemplary behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with 'HDF5 / scientific-array EDA' and follows a logical flow: context → mechanics → reports → edge cases → output size. Every sentence delivers meaningful information with no filler, making it appropriately sized for the tool's complexity.
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 tool of this complexity with no annotations, the description covers the modality prerequisite, detailed operational behavior, edge case handling (cap), expected output content, and output size. Combined with the presence of an output schema, this is completely sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only names and types (source_id required, max_groups integer default 10000). The description adds rich semantics for max_groups: caps walk depth, cap_hit triggers critical finding, and advises raising max_groups. source_id is not explicitly explained but is intuitive as a standard identifier. Given 0% schema coverage, this compensation is strong.
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 'HDF5 / scientific-array EDA' and details the action: 'Walks the h5py tree and aggregates leaf datasets by their leaf name.' This clearly identifies the tool's specific verb, resource, and scope, and distinguishes it from other check_* tools that focus on distributions, correlations, or quality.
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?
A clear prerequisite is stated: 'Source must be loaded as hdf5 modality.' It also explains when to adjust max_groups for large files. However, no explicit alternatives or when-not-to-use conditions are given, leaving some ambiguity among similar sibling tools.
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. It adds useful behavioral details: accepts file/directory/glob, output size is small, and results are capped at max_files. It doesn't mention error handling or permissions, but the disclosed traits are valuable for an agent.
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 compact and front-loaded. The first sentence states the core action, and the remaining sentences add usage guidance, an alternative, and output size—all without redundancy. Every sentence earns its place.
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 simple file-listing tool with an output schema, the description covers purpose, usage, alternatives, and output characteristics. It is sufficiently complete given the tool's low complexity and 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameter descriptions (coverage 0%), so the description must compensate. It adds meaning to `path` by noting it can be a file, directory, or glob, and to `max_files` by stating it caps the file list. This goes beyond the raw schema, though it leaves some details (like default behavior) to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List files under `path` (file, directory, or glob).' It distinguishes itself from siblings by mentioning use before load_source and contrasting with detect_pattern(), making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Useful when you don't know what's in a directory and need to find a specific file before calling load_source' and directs users to 'prefer detect_pattern()' for HDF5/array directories. This covers both when to use and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It discloses the return format, output size (small, top-10 findings), side effect (full results written to artifact), and the conditional behavior that temporal checks only run when hints.time_column is provided. This gives an agent a solid behavioral model before invoking the 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 efficiently structured with a concise opening sentence followed by scannable bullet points for presets and hints. Every sentence adds value: preset levels, runtime estimates, conditional temporal behavior, hint keys, and output size. There is no filler or repetition of schema information.
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?
The description is complete for a tool of this complexity and rich parameter space. It covers all presets, the hints mechanism and its benefits, conditional temporal behavior, and the returned payload. The output schema is available separately, so the description's return-value summary is sufficient. An agent can confidently decide whether to run this tool and how to configure it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 so thoroughly: preset values are fully enumerated with levels and runtime, and hints are explained with a list of keys and their effect on downstream checks. source_id is not explicitly described but its purpose as the target source is self-evident from the name and sibling tools. All three parameters are made actionable.
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: "Run a preset bundle of checks." It clearly differentiates this aggregate EDA tool from the many individual check siblings (e.g., check_quality, check_bias) by emphasizing presets and the returned summary card, run_id, and artifact path. The purpose is unambiguous and well-scoped.
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 preset breakdown (quick, standard, deep, exhaustive) provides clear context for when to use each level, including runtime estimates and included checks. The hints section explains when to provide hints (to unlock leakage/bias checks and pre-fill follow-up calls). However, it does not explicitly state when to prefer this bundled tool over running individual check tools directly, so it lacks explicit exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses the 5-8 plot sequence, the JSON + inline image return format, that plots are written to disk regardless, and the downsample/reservoir sampling behavior with OOM risk and `sample_info` exposure.
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 longer than average but every sentence earns its place, covering purpose, usage boundaries, return formats, parameter behavior, and failure modes. It is front-loaded with the most important usage instruction and uses paragraph breaks to separate distinct concerns, making it easy to scan.
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?
Despite having no output schema, the description fully explains the return value structure (paste-ready Markdown + section list, optional inline ImageContent, `sample_info`). It also warns about common pitfalls (filename-collision bugs, maximum call stack errors, OOM) that are critical for an agent to choose and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, so the description must compensate. It richly explains `max_rows` (reservoir sampling, OOM prevention, `sample_info`) and `inline_images` (default true, false for stack-overflow clients, file:// paths only). `source_id` is contextually obvious, but the `hints` parameter is never elaborated, leaving a minor gap.
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 bold, specific directive: 'Use ONLY for walk me through the dataset / full visual tour requests' and enumerates the exact plot sequence (missingness, distribution, Q-Q, correlations, pairs, time, grouped). It clearly distinguishes itself from siblings by directing specific questions to `plot_distribution`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('walk me through the dataset' / full visual tour requests) and when not to (specific distribution questions should call `plot_distribution` or similar direct plotting tools). It also gives a concrete fallback behavior (`inline_images=False`) for clients that cannot handle the multi-image response.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses path resolution behavior (absolute path vs. leaf name, first-match with other_matches), n default and payload cap (~500 values), and output contents (dtype, full shape, JSON-safe values, units, valid_range). This exceeds typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: main purpose, usage rationale, parameter specifics, and output summary. Each sentence adds necessary detail, and the format uses bullet-like breaks for readability without redundancy.
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?
Despite having an output schema, the description elaborates on output fields (dtype, shape, JSON-safe values, attributes) and includes safety constraints. It covers path edge cases and fallback behavior, making it complete for a read-only inspection 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 define parameters. It thoroughly explains 'path' (two accepted forms) and 'n' (row count, default 5, cap). 'source_id' is only implied by context (identifying the HDF5 source), not explicitly described, a minor gap.
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: 'Read a small slice from one HDF5 dataset'. It also distinguishes itself from siblings by calling itself 'the missing companion to check_arrays' and contrasting with sample_rows/run_sql, which cannot inspect HDF5 sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: HDF5 sources don't have SQL views, so sample_rows/run_sql can't inspect them. It directly says 'Use this to read raw values,' providing clear context and an implicit alternative comparison.
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:

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

Score Badge

Copy to your README.md:

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

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/charliecpeterson/edamcp'

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