The VayuChat MCP server enables natural language analysis of air quality and other datasets through predefined functions without requiring code for common tasks.
Data Management: Load CSV files into named DataFrames, list/unload datasets, inspect structure and details, query with pandas syntax, and sample rows.
Statistical Analysis: Generate statistical summaries, compare groups (e.g., cities), analyze weekday vs weekend patterns, examine hourly and temporal trends, perform correlation analysis, and identify top/bottom records.
Visualization: Create comparison charts (bar, box plots), time series plots, distribution histograms, hourly pattern plots, and weekday/weekend comparisons—all returned as base64-encoded PNG images.
Advanced Customization: Execute arbitrary Python code for complex analyses with access to pandas, numpy, matplotlib, and all loaded DataFrames.
Pre-loaded Datasets: Air quality data (PM2.5, PM10, NO2, SO2, CO, O3), government funding data, and city metadata for immediate analysis.
Hybrid Architecture: Combines natural language understanding with reliable predefined functions for consistent, user-friendly data exploration.
Provides access to numerical computing and array manipulation capabilities within the code execution environment for data analysis.
Enables loading CSV files into DataFrames, performing statistical summaries, querying datasets, and managing data structures through natural language.
Allows for the execution of Python code to perform complex data analysis and generate visualizations using pandas, numpy, and matplotlib.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@VayuChat MCP Load sales.csv and plot a bar chart of total revenue by region."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Natural language data analysis for air quality data using MCP (Model Context Protocol).
air_quality: Hourly PM2.5, PM10, NO2, SO2, CO, O3 readings for Delhi & Bangalore
funding: Government air quality funding by city/year (2020-2024)
city_info: City metadata - population, vehicles, industries, green cover
Function | Description |
| Show available tables |
| Display table data |
| Detailed statistics |
| Filter with pandas query |
| Weekday vs weekend analysis |
| Compare metrics across cities |
| Correlation analysis |
| Funding breakdown |
| Comprehensive city profile |
Function | Description |
| Bar/box charts |
| Time series charts |
| Weekday vs weekend bars |
| Funding over years |
| Hourly patterns |
Related MCP server: mcp-csv-analyst
# Using uv
uv pip install -e .
# Or with pip
pip install -e .Add to your Claude Code MCP configuration:
{
"mcpServers": {
"vayuchat": {
"command": "uv",
"args": ["run", "--directory", "/path/to/vayuchat-mcp", "vayuchat-mcp"]
}
}
}# Run locally
python app.py
# Or with gradio
gradio app.pyThen open http://localhost:7860
Create a new Space on HF (Gradio SDK)
Upload these files:
app.py
requirements.txt
src/ folder
data/ folder
Or connect your GitHub repo directly to HF Spaces.
# Data exploration
"What tables are available?"
"Show me the funding table"
"Describe the air quality data"
# Analysis
"Compare weekday vs weekend PM2.5"
"Compare cities by PM10 levels"
"Get Delhi city profile"
"Show correlation with PM2.5"
# Funding
"Show funding for Delhi"
"What's the funding trend?"
# Visualizations
"Plot weekday vs weekend PM2.5"
"Show hourly pattern for NO2"
"Plot funding trend chart"NLQ (User Question)
↓
Gradio Chat UI
↓
Query Router (keyword-based / LLM)
↓
MCP Tool Call
↓
Response (Markdown + Base64 Plot)
↓
Rendered in UIThis project uses predefined MCP functions instead of letting the LLM generate arbitrary pandas/matplotlib code. Here's why:
Aspect | Predefined Functions (This Approach) | LLM-Generated Code | Function-Calling LLM |
Reliability | ✅ Deterministic, always works | ❌ May hallucinate syntax | ⚠️ Better but can miss params |
Speed | ✅ Instant (no code generation) | ❌ Slow (generate → parse → execute) | ⚠️ Moderate |
Cost | ✅ Minimal tokens | ❌ Long prompts with schema | ⚠️ Moderate |
Security | ✅ No arbitrary code execution | ❌ Code injection risk | ✅ Safe |
Consistency | ✅ Same visualization style | ❌ Random styling each time | ✅ Consistent |
Model Size | ✅ Works with small/cheap models | ❌ Needs capable coder model | ⚠️ Needs fine-tuned model |
Flexibility | ❌ Limited to predefined queries | ✅ Infinite flexibility | ⚠️ Limited to defined functions |
Error Handling | ✅ Graceful, predictable | ❌ May crash, retry loops | ✅ Structured errors |
Use Predefined Functions (this approach) when:
You have a known, bounded set of analysis patterns
Users are non-technical (need consistent UX)
Cost/latency matters (production deployment)
You want guaranteed correct outputs
Using smaller/cheaper models (Haiku, GPT-3.5)
Use LLM-Generated Code when:
Exploratory data analysis with unknown patterns
Power users who can debug code
One-off analyses
Prototype/research phase
Use Function-Calling LLM when:
You have predefined functions BUT need better intent parsing
Using OpenAI/Claude with native function calling
Queries are ambiguous and need sophisticated NLU
User Query
↓
┌─────────────────────────────────────┐
│ LLM with Function Calling │ ← Parses intent, extracts params
│ (Claude, GPT-4, etc.) │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ MCP Predefined Functions │ ← Executes reliably
│ (compare_cities, plot_trend, etc.) │
└─────────────────────────────────────┘
↓
Structured Response + PlotThis gives you:
LLM's NLU capabilities for parsing complex queries
Predefined functions' reliability for execution
No code hallucination risk
Consistent outputs every time
Query: "Compare PM2.5 on weekdays vs weekends for Delhi and Bangalore"
LLM-Generated Code (risky):
# LLM might generate:
df['is_weekend'] = df['day'].isin(['Sat', 'Sun']) # Wrong column name!
df.groupby(['city', 'is_weekend'])['pm25'].mean() # Wrong column name!
# ... errors, retries, inconsistent outputPredefined Function (reliable):
# MCP calls:
compare_weekday_weekend(value_column="PM2.5", group_by="city")
# Always works, consistent format, proper column namesApproach | Tokens per Query | Cost (GPT-4) | Latency |
Predefined + Keyword Router | ~100 | $0.001 | <100ms |
Predefined + LLM Router | ~500 | $0.005 | ~500ms |
LLM-Generated Code | ~2000+ | $0.02+ | 2-5s |
For 1000 queries/day:
Predefined: ~$1-5/day
LLM Code Gen: ~$20+/day
Air quality data: Simulated based on real patterns from Indian cities
Funding data: Mock data representing typical government allocations
City info: Approximate real statistics
MIT
Analyze correlations between numeric columns.
Args: columns: Optional list of columns to analyze target: Optional target column to show correlations with table: Table name (default: air_quality)
Returns: Correlation analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| columns | No | ||
| target | No | ||
| table | No | air_quality |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool analyzes correlations but lacks details on how it handles missing data, what correlation method is used (e.g., Pearson), whether it's read-only or modifies data, or any performance considerations. This is insufficient for a tool with potential data processing implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by 'Args' and 'Returns' sections. It's front-loaded and uses bullet-like formatting efficiently. However, the 'Returns' section is vague ('Correlation analysis.'), which slightly reduces conciseness by not adding value beyond what the output schema might provide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and an output schema present, the description partially compensates by listing parameters but lacks depth. It doesn't explain the analysis method, data requirements, or error handling. The output schema existence means return values needn't be detailed, but overall completeness is minimal for a statistical tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 lists parameters in the 'Args' section, explaining 'columns', 'target', and 'table' with minimal context (e.g., 'Optional list of columns to analyze'). However, it doesn't clarify what 'correlation analysis' entails for these inputs or provide examples, leaving gaps in understanding parameter usage beyond basic definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze correlations between numeric columns.' It specifies the verb ('analyze') and resource ('numeric columns'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'compare_cities' or 'plot_comparison', which might also involve correlation analysis, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention sibling tools or contexts where this analysis is preferred over others, such as 'plot_comparison' for visual correlation or 'describe_table' for general statistics. This leaves the agent without explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze air quality funding data.
Args: city: Optional city to filter by year: Optional year to filter by
Returns: Funding analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| year | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Analyze' suggests a read operation, it doesn't clarify what type of analysis is performed, whether it requires specific permissions, what format the analysis takes, or any limitations. The description is too minimal for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear purpose statement followed by parameter and return sections. However, the 'Returns' section is redundant since an output schema exists, and the parameter documentation is insufficient given the 0% schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with no annotations and 0% schema coverage. While an output schema exists (reducing the need to describe return values), the description fails to adequately explain the tool's behavior, parameter usage, or differentiation from siblings. It's minimally viable but has significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description only lists parameter names ('city', 'year') without explaining their purpose, format requirements, or constraints. It doesn't compensate for the complete lack of schema documentation, leaving parameters essentially undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Analyze air quality funding data' which provides a clear verb ('analyze') and resource ('air quality funding data'), but it's somewhat vague about what specific analysis is performed. It doesn't distinguish this tool from potential sibling tools like 'plot_funding_trend' or 'compare_cities' that might also analyze funding data in different ways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With siblings like 'plot_funding_trend', 'compare_cities', and 'query_table' that might handle similar data, there's no indication of when this specific analysis tool is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare a metric across cities.
Args: value_column: Column to compare (e.g., 'PM2.5') cities: Optional list of cities to compare table: Table name (default: air_quality)
Returns: City comparison statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| value_column | Yes | ||
| cities | No | ||
| table | No | air_quality |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions that the tool returns 'City comparison statistics,' but does not detail what these statistics include, how data is sourced, any rate limits, or error handling. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a clear purpose statement followed by structured sections for Args and Returns. Each sentence adds value without redundancy, making it efficient. However, the 'Returns' section is vague, slightly reducing its conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, but with an output schema), the description is moderately complete. It covers the basic purpose and parameters but lacks details on behavioral aspects and usage context. The presence of an output schema helps, but the description should do more to compensate for the missing annotations and low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning beyond the input schema, such as examples for 'value_column' (e.g., 'PM2.5') and default values for 'table' and 'cities.' However, with 0% schema description coverage, it does not fully compensate for the lack of schema details, leaving parameters like 'cities' and 'table' partially explained but not comprehensively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compare a metric across cities.' It specifies the verb 'compare' and the resource 'cities,' making it understandable. However, it does not explicitly differentiate from siblings like 'get_city_profile' or 'plot_comparison,' which might have overlapping functions, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention any context, prerequisites, or exclusions, such as when to choose 'compare_cities' over 'plot_comparison' or 'get_city_profile' for similar tasks. This lack of usage instructions limits its effectiveness for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare weekday vs weekend values for a metric.
Args: value_column: Column to compare (e.g., 'PM2.5', 'PM10') group_by: Optional grouping column (e.g., 'city') table: Table name (default: air_quality)
Returns: Comparison statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| value_column | Yes | ||
| group_by | No | ||
| table | No | air_quality |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions what the tool does but lacks critical behavioral details: it doesn't specify what statistical methods are used for comparison, whether it modifies data, what permissions are needed, or how results are structured beyond 'comparison statistics'. For a tool with no annotations, this is insufficient disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The Args and Returns sections are structured but could be more integrated. There's minimal waste, though the formatting as separate sections slightly reduces flow. Overall, it's efficient but not perfectly polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, 0% schema coverage) and the presence of an output schema, the description is minimally adequate. The output schema likely covers return values, reducing the need for detailed return explanations. However, with no annotations and incomplete parameter semantics, it leaves gaps in behavioral context and usage guidance, making it just viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds some meaning by providing examples for 'value_column' and 'group_by' (e.g., 'PM2.5', 'city') and clarifies the default for 'table'. However, it doesn't fully explain parameter constraints or interactions, leaving gaps like valid column names or grouping effects. This partial compensation earns a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compare weekday vs weekend values for a metric.' This specifies the verb ('compare'), resource ('weekday vs weekend values'), and scope ('for a metric'). However, it doesn't explicitly differentiate from sibling tools like 'plot_weekday_weekend' or 'compare_cities', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There are multiple sibling tools that might overlap (e.g., 'plot_weekday_weekend', 'compare_cities', 'query_table'), but no explicit when/when-not instructions or named alternatives are mentioned. The context is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed statistics for a table.
Args: name: Table name
Returns: Statistical summary and column info.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions that the tool returns 'statistical summary and column info', it lacks details on permissions needed, rate limits, whether it's a read-only operation, or how the data is formatted. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The additional sections for 'Args' and 'Returns' are structured but slightly verbose for such a simple tool. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema, the description covers the basics but has gaps. It explains what the tool does and the parameter meaning, but without annotations, it lacks behavioral context like safety or performance considerations, making it only adequate for a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description adds minimal parameter semantics by specifying that 'name' is the 'Table name'. This provides basic context beyond the schema, but it doesn't elaborate on format constraints, examples, or how the name should be specified (e.g., case sensitivity, database context).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed statistics for a table'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'list_tables' or 'show_table', which might also provide table information but with different scopes or formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With siblings like 'list_tables', 'show_table', and 'query_table' available, there's no indication of what makes this tool unique or when it should be preferred over others for accessing table details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute custom Python code for advanced analysis.
Available variables:
air_quality, funding, city_info: DataFrames
pd, np, plt: Libraries
Args: code: Python code to execute
Returns: Output from code execution.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 available variables (DataFrames and libraries) and the return behavior, but lacks critical details: it doesn't mention security implications (e.g., sandboxing), execution limits (e.g., timeouts), error handling, or data mutation risks. For a code execution tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. The bullet points for variables and libraries are efficient, and the Args/Returns sections are clear. However, the 'Available variables' section could be integrated more seamlessly, and some redundancy exists (e.g., 'Returns' repeats 'Output from code execution').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (code execution with data access) and lack of annotations, the description is incomplete. It covers purpose and available resources but misses safety, limits, and error details. The output schema exists, so return values needn't be explained, but critical behavioral aspects are omitted, making it adequate only for basic use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema. It states the 'code' parameter is 'Python code to execute', which the schema (with 0% description coverage) doesn't specify. However, it doesn't elaborate on syntax, constraints, or examples. With one parameter and low schema coverage, the description partially compensates but remains basic, aligning with the baseline for moderate coverage scenarios.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute custom Python code for advanced analysis.' It specifies the verb ('Execute') and resource ('custom Python code'), and distinguishes it from sibling tools by emphasizing custom code execution rather than predefined analyses. However, it doesn't explicitly differentiate from siblings like 'query_table' or 'analyze_correlation' beyond the custom code aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions 'advanced analysis' but doesn't specify contexts, prerequisites, or exclusions. Given siblings like 'analyze_correlation' and 'plot_time_series', the agent lacks clear criteria for choosing this tool over others for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive profile for a city including all available data.
Args: city: City name (Delhi, Bangalore, Mumbai, etc.)
Returns: City profile with air quality, funding, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions the tool returns a 'comprehensive profile' with 'air quality, funding, and metadata', but doesn't disclose behavioral traits like whether it's a read-only operation, if it requires specific permissions, rate limits, or error handling. The description is minimal and lacks crucial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. The 'Args' and 'Returns' sections add structure without redundancy. However, the phrase 'including all available data' is slightly vague and could be more precise, but overall it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, the description doesn't need to explain return values in detail, and it mentions key components like 'air quality, funding, and metadata'. However, with no annotations and a simple input schema, the description lacks context on usage scenarios, error cases, or integration with sibling tools, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It specifies the 'city' parameter as 'City name (Delhi, Bangalore, Mumbai, etc.)', providing examples and clarifying it's a string input. This compensates well for the schema's lack of description, though it doesn't detail format constraints like case sensitivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('comprehensive profile for a city'), specifying it includes 'all available data'. It distinguishes from siblings like 'compare_cities' or 'analyze_funding' by focusing on a single city's full profile. However, it doesn't explicitly contrast with 'query_table' or 'describe_table', which might overlap in data access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, it doesn't mention if this is preferred over 'query_table' for city-specific data or when 'compare_cities' might be better for multi-city analysis. The description implies usage for a single city but lacks explicit exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available tables/dataframes with their descriptions.
Returns: Summary of all available tables.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions that the tool returns a 'Summary of all available tables,' which gives some context about the output format. However, it lacks details on permissions, rate limits, or any side effects, which is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the main purpose stated clearly in the first sentence. The second sentence adds value by describing the return format. There's no unnecessary information, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should cover return values), the description doesn't need to explain return values in detail. However, with no annotations and siblings that might overlap, the description could do more to clarify usage context and behavioral traits. It's adequate but has clear gaps in guiding the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate in this case. It focuses on the tool's purpose and output, aligning well with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all available tables/dataframes with their descriptions.' It specifies the verb ('List') and resource ('tables/dataframes'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'show_table' or 'describe_table', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With siblings like 'show_table' and 'describe_table' that might also retrieve table information, there's no indication of when this tool is preferred or what distinguishes it. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a comparison chart.
Args: value_column: Column to plot (e.g., 'PM2.5') group_column: Grouping column (default: 'city') chart_type: 'bar', 'horizontal_bar', or 'box' table: Table name title: Optional title
Returns: Base64 encoded plot.
| Name | Required | Description | Default |
|---|---|---|---|
| value_column | Yes | ||
| group_column | No | city | |
| chart_type | No | bar | |
| table | No | air_quality | |
| title | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a chart and returns a Base64 encoded plot, but it fails to disclose critical traits like whether this is a read-only or mutating operation, any authentication needs, rate limits, error handling, or how the chart is generated (e.g., from a database query). This is a significant gap for a tool with 5 parameters and no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the main purpose ('Create a comparison chart.') followed by a structured 'Args:' and 'Returns:' section. Each sentence adds value without redundancy, though the formatting could be slightly more polished for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 0% schema coverage, no annotations) and the presence of an output schema (implied by 'Returns: Base64 encoded plot'), the description is partially complete. It covers the basic purpose and parameters but lacks behavioral context and detailed usage guidelines, making it adequate but with clear gaps for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning beyond the input schema by providing examples (e.g., 'PM2.5' for value_column) and listing chart_type options ('bar', 'horizontal_bar', 'box'), which the schema does not include. However, with 0% schema description coverage and 5 parameters, it only partially compensates—key parameters like 'table' and 'title' lack semantic context, and it doesn't explain how parameters interact (e.g., grouping logic).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a comparison chart.' This specifies the verb ('Create') and resource ('comparison chart'), making it understandable. However, it does not explicitly differentiate from sibling tools like 'plot_funding_trend' or 'plot_time_series', which might also create charts but for different purposes, leaving some ambiguity in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It lacks any mention of context, prerequisites, or exclusions, such as when to choose this over other plotting tools like 'plot_time_series' for time-based data or 'compare_cities' for city comparisons. This absence leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plot funding trends over years by city.
Args: cities: Optional list of cities to include title: Optional title
Returns: Base64 encoded plot.
| Name | Required | Description | Default |
|---|---|---|---|
| cities | No | ||
| title | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions that the tool returns a 'Base64 encoded plot', which is useful context about the output format. However, it lacks critical details such as what data source is used, whether it requires specific permissions, how it handles missing data, or any rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured. It starts with a clear purpose statement, followed by brief but informative sections for 'Args' and 'Returns'. Every sentence earns its place, with no redundant or vague language. The information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (plotting with parameters), no annotations, and an output schema that likely only specifies the Base64 string format, the description is minimally adequate. It covers the purpose and parameters but lacks context on data sources, error handling, or integration with sibling tools. The presence of an output schema reduces the need to explain return values, but more behavioral details would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'cities' is an 'Optional list of cities to include' and 'title' is an 'Optional title', clarifying their purposes and optional nature. This compensates well for the schema's lack of descriptions, though it doesn't specify format details (e.g., city naming conventions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Plot funding trends over years by city.' This specifies the verb ('Plot'), resource ('funding trends'), and scope ('over years by city'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'plot_time_series' or 'plot_comparison', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With multiple sibling plotting tools (e.g., 'plot_time_series', 'plot_comparison', 'plot_hourly_pattern'), there's no indication of how this tool differs or when it's the appropriate choice. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plot hourly patterns.
Args: value_column: Column to plot group_by: Optional grouping column table: Table name title: Optional title
Returns: Base64 encoded plot.
| Name | Required | Description | Default |
|---|---|---|---|
| value_column | Yes | ||
| group_by | No | city | |
| table | No | air_quality | |
| title | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions that the tool returns a 'Base64 encoded plot', which is useful, but lacks critical details: it doesn't specify the plot type (e.g., line chart, bar chart), default behaviors (e.g., how 'group_by' affects the plot), error handling, or any performance considerations. For a plotting tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with 'Plot hourly patterns', followed by a structured 'Args' and 'Returns' section. Every sentence adds value: the first states the purpose, and the subsequent lines document parameters and output. There's no wasted text, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a plotting tool with 4 parameters, no annotations, and an output schema that likely defines the Base64 string), the description is minimally complete. It covers the basic purpose, parameters, and return type, but lacks details on plot specifics, usage context, and behavioral traits. The presence of an output schema means it doesn't need to explain return values further, but overall, it's adequate with clear gaps in guidance and transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 lists the parameters ('value_column', 'group_by', 'table', 'title') and adds some meaning by noting 'Column to plot' and 'Optional grouping column', but it doesn't explain the semantics deeply (e.g., what 'value_column' represents, how 'group_by' influences the plot, what 'table' refers to). With 4 parameters and low schema coverage, this provides basic clarification but falls short of fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Plot hourly patterns' which indicates a visualization function, but it's vague about what specifically constitutes 'hourly patterns' (e.g., trends, distributions, averages). It distinguishes from some siblings like 'analyze_correlation' or 'describe_table' by focusing on plotting, but doesn't clearly differentiate from similar plotting tools like 'plot_time_series' or 'plot_comparison' in terms of what makes 'hourly' patterns unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites, such as needing time-based data, or compare it to siblings like 'plot_time_series' or 'plot_weekday_weekend' that might also handle temporal data. There's no indication of when this tool is preferred or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a time series plot.
Args: value_column: Column to plot group_by: Optional column for separate lines (e.g., 'city') table: Table name title: Optional title
Returns: Base64 encoded plot.
| Name | Required | Description | Default |
|---|---|---|---|
| value_column | Yes | ||
| group_by | No | ||
| table | No | air_quality | |
| title | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a plot and returns Base64 encoded output, which covers the basic operation. However, it lacks critical behavioral details: whether this is a read-only operation, what permissions are needed, whether it modifies data, how errors are handled, or any rate limits. For a tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and uses bullet points efficiently. Each sentence adds value: the purpose statement, parameter explanations, and return format. However, the 'Create a time series plot' line is somewhat redundant with the tool name, and the parameter explanations could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, 0% schema coverage, but has output schema), the description is moderately complete. It covers the purpose, parameters, and return format. However, it lacks behavioral context, usage guidelines, and detailed parameter constraints. The output schema existence means the description doesn't need to explain return values, but other gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds semantic meaning for all 4 parameters, explaining what each represents (e.g., 'value_column: Column to plot', 'group_by: Optional column for separate lines'). However, it doesn't provide format details, constraints, or examples beyond basic definitions. This partially compensates for the schema gap but leaves implementation details unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Create a time series plot' with a specific verb ('create') and resource ('time series plot'). It distinguishes from siblings like 'plot_comparison' or 'plot_hourly_pattern' by specifying the plot type. However, it doesn't explicitly differentiate from all siblings (e.g., 'plot_funding_trend' might also create time series plots).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention when this tool is appropriate, what prerequisites exist, or how it differs from sibling tools like 'plot_funding_trend' or 'plot_hourly_pattern' that might also create visualizations. The agent must 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.
Create weekday vs weekend comparison chart.
Args: value_column: Column to compare group_by: Grouping column (default: 'city') table: Table name title: Optional title
Returns: Base64 encoded plot.
| Name | Required | Description | Default |
|---|---|---|---|
| value_column | Yes | ||
| group_by | No | city | |
| table | No | air_quality | |
| title | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions that the tool creates a chart and returns a Base64 encoded plot, it lacks critical details: it doesn't specify what type of chart is generated (e.g., bar, line), whether it modifies data, requires specific permissions, has rate limits, or handles errors. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured 'Args' and 'Returns' section. Each sentence adds value without redundancy, making it efficient. However, the formatting with bullet-like sections could be slightly improved for readability, but it remains concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 0% schema coverage, no annotations, but has an output schema), the description is partially complete. It covers the purpose and parameters but lacks behavioral details and usage guidelines. The output schema existence means return values are documented elsewhere, reducing the burden, but without annotations, more context on tool behavior is needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 lists parameters (value_column, group_by, table, title) and adds some meaning: value_column is 'Column to compare', group_by is 'Grouping column' with a default, table is 'Table name', and title is 'Optional title'. However, it doesn't fully explain semantics (e.g., what 'compare' entails, valid column types, table constraints), leaving gaps despite covering all parameters nominally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create weekday vs weekend comparison chart.' This specifies the verb ('create') and resource ('weekday vs weekend comparison chart'), making the function unambiguous. However, it doesn't explicitly differentiate from the sibling tool 'compare_weekday_weekend' or other plotting tools like 'plot_comparison', leaving room for potential confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention sibling tools like 'compare_weekday_weekend' (which might serve a similar purpose) or other plotting tools such as 'plot_comparison', nor does it specify prerequisites, exclusions, or contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter a table using pandas query syntax.
Args: name: Table name query: Pandas query (e.g., "city == 'Delhi' and PM2.5 > 200")
Returns: Filtered results.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool filters tables but lacks details on permissions, error handling, performance implications, or what happens if the query fails. This is a significant gap for a tool with mutation-like filtering operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement, parameter explanations, and return information in three concise sentences. Every sentence adds value without redundancy, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is adequate but incomplete. It covers the basic operation and parameters but lacks behavioral context and usage guidelines. The output schema existence reduces the need to explain return values, but more guidance is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds meaningful context by explaining that 'name' is the table name and 'query' uses pandas syntax with an example, clarifying semantics beyond the bare schema. However, it doesn't detail constraints like valid table names or query limitations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Filter a table using pandas query syntax,' which specifies the verb (filter) and resource (table). It distinguishes from siblings like 'list_tables' or 'show_table' by focusing on filtering, but doesn't explicitly differentiate from all alternatives like 'compare_cities' or 'analyze_correlation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It mentions pandas query syntax but doesn't specify scenarios where filtering is preferred over other operations like comparing or describing tables, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Display rows from a table.
Args: name: Table name (air_quality, funding, city_info) rows: Number of rows to show (default: 10) columns: Optional list of columns to display
Returns: Formatted table data.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| rows | No | ||
| columns | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions that the tool displays data and returns formatted table data, but it doesn't cover important aspects like whether this is a read-only operation, if there are rate limits, authentication requirements, or how errors are handled. For a data retrieval tool with zero annotation coverage, this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by parameter explanations and return information. It uses bullet-like formatting under 'Args' and 'Returns' for readability. Every sentence adds value, and there's no redundant information, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which handles return values), the description doesn't need to detail output specifics. However, with no annotations and 0% schema description coverage, it partially compensates by explaining parameters. It's adequate for a simple data display tool but lacks behavioral context and usage guidelines, making it incomplete for optimal agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains each parameter: 'name' as the table name with examples, 'rows' as the number of rows with a default, and 'columns' as an optional list. However, with 0% schema description coverage, the schema provides no additional details. The description compensates somewhat by adding examples and defaults, but it doesn't fully clarify data types or constraints beyond what's implied, leaving room for improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Display rows from a table.' It specifies the verb 'display' and resource 'rows from a table,' making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'list_tables' (which likely lists table names) or 'query_table' (which might allow more complex queries), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention siblings such as 'list_tables' for listing table names or 'query_table' for more complex queries, nor does it specify prerequisites like needing to know table names beforehand. This lack of context makes it harder for an agent to choose correctly among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_correlationanalyze_fundingcompare_citiescompare_groupscompare_weekday_weekend5 fields changedInput schema / properties / date_columnRemoved value: -{
- "default": "date",
- "type": "string"
-}Input schema / properties / day_of_week_columnRemoved value: -{
- "default": "day_of_week",
- "type": "string"
-}Input schema / properties / nameRemoved value: -{
- "type": "string"
-}Input schema / properties / tableAdded value: +{
+ "default": "air_quality",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "name",
- "value_column"
-]New value: +[
+ "value_column"
+]correlation_analysisdescribe_dataframedescribe_tableget_city_profileget_column_valuesget_dataframe_infohourly_patternlist_dataframeslist_tablesload_csvplot_comparison4 fields changedInput schema / properties / group_column / defaultAdded value: +"city"Input schema / properties / nameRemoved value: -{
- "type": "string"
-}Input schema / properties / tableAdded value: +{
+ "default": "air_quality",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "name",
- "value_column",
- "group_column"
-]New value: +[
+ "value_column"
+]plot_distributionplot_funding_trendplot_hourly_pattern5 fields changedInput schema / properties / group_by / defaultPrevious value: -nullNew value: +"city"Input schema / properties / hour_columnRemoved value: -{
- "default": "hour",
- "type": "string"
-}Input schema / properties / nameRemoved value: -{
- "type": "string"
-}Input schema / properties / tableAdded value: +{
+ "default": "air_quality",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "name",
- "value_column"
-]New value: +[
+ "value_column"
+]plot_time_series4 fields changedInput schema / properties / date_columnRemoved value: -{
- "default": "date",
- "type": "string"
-}Input schema / properties / nameRemoved value: -{
- "type": "string"
-}Input schema / properties / tableAdded value: +{
+ "default": "air_quality",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "name",
- "value_column"
-]New value: +[
+ "value_column"
+]plot_weekday_weekend5 fields changedInput schema / properties / day_of_week_columnRemoved value: -{
- "default": "day_of_week",
- "type": "string"
-}Input schema / properties / group_by / defaultPrevious value: -nullNew value: +"city"Input schema / properties / nameRemoved value: -{
- "type": "string"
-}Input schema / properties / tableAdded value: +{
+ "default": "air_quality",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "name",
- "value_column"
-]New value: +[
+ "value_column"
+]query_dataframequery_tablesample_dataframeshow_tabletop_bottom_analysistrend_analysisunload_dataframecompare_groupscompare_weekday_weekendcorrelation_analysisdescribe_dataframeexecute_codeget_column_valuesget_dataframe_infohourly_patternlist_dataframesload_csvplot_comparisonplot_distributionplot_hourly_patternplot_time_seriesplot_weekday_weekendquery_dataframesample_dataframetop_bottom_analysistrend_analysisunload_dataframeScored across 15 tools
Most tools have distinct purposes focused on air quality data analysis, but some overlap exists between plot tools (e.g., plot_time_series and plot_hourly_pattern could be confused for time-based visualizations) and between describe_table and show_table for data inspection. The descriptions help differentiate them, but careful reading is needed.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., analyze_correlation, compare_cities, plot_time_series). The naming is predictable and readable throughout the set, with no deviations in style.
15 tools are well-scoped for an air quality data analysis server, covering data querying, statistical analysis, visualization, and custom code execution. Each tool earns its place without feeling excessive or insufficient for the domain.
The toolset provides comprehensive coverage for air quality analysis, including data inspection, filtering, statistical comparisons, and various visualizations. A minor gap is the lack of tools for data modification (e.g., update or delete operations), but this is reasonable for an analysis-focused server, and agents can work around it with execute_code if needed.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
GibsonAI MCP server: manage your databases with natural language
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
The Needle MCP server enables semantic search on documents stored in files like PDFs, DOCX, and XLSX by connecting AI applications to external data sources. It provides capabilities to create and manage document collections, perform natural language searches on stored content, and retrieve relevant information without requiring exact keyword matches.
