Superset MCP Integration

by aptro

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Tools are organized by resource type (chart, dashboard, database, etc.) and action (create, get, list, update, delete), making it easy to distinguish between them. For example, superset_chart_create and superset_chart_update are clearly different operations on the same resource.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with a superset_ prefix, using snake_case throughout. The naming convention is highly predictable: superset_resource_action (e.g., superset_dashboard_list, superset_database_create). There are no deviations in style or structure across all 60 tools.
Tool Count2/5
With 60 tools, this is an extremely large set that feels overwhelming for an MCP server. While Superset is a complex platform, 60 tools will be difficult for agents to navigate and may cause confusion. This exceeds the typical well-scoped range of 3-15 tools and approaches the extreme mismatch threshold.
Completeness5/5
The tool surface provides comprehensive coverage of the Superset API domain with complete CRUD operations for all major resources (charts, dashboards, databases, datasets, tags, etc.). There are no obvious gaps - the tools cover authentication, data exploration, SQL execution, metadata management, and user operations, providing full lifecycle support.
Average 3.4/5 across 60 of 60 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions making an API request and returning a dictionary, it doesn't describe error handling, authentication requirements, rate limits, or what happens with invalid inputs. The description doesn't specify whether this is a read-only operation or has side effects, nor does it explain what 'advanced data type format' means in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with clear sections (purpose, endpoint, args, returns). Each sentence serves a purpose, and the structure helps parsing. However, the first sentence 'Convert a value to an advanced data type' could be more informative by specifying what makes it 'advanced' versus regular conversion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what advanced data types are available, provide examples of conversions, describe error cases, or reference the sibling tool 'superset_advanced_data_type_list' which might be prerequisite knowledge. The agent lacks sufficient context to use this tool effectively without trial and error.
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 for both parameters, the description must compensate but provides minimal additional context. It states 'type_name: Name of the advanced data type' and 'value: Value to convert' but doesn't explain what constitutes a valid type_name (are there predefined types? where are they listed?), what formats the value can be in, or provide examples. The description adds basic labels but insufficient semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Convert a value to an advanced data type' which provides a basic verb+resource combination. However, it's vague about what 'advanced data type' means in this context and doesn't distinguish this tool from potential alternatives like 'superset_advanced_data_type_list' (which might list available types). The description lacks specificity about what constitutes an 'advanced' data type versus regular data types.
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. There's no mention of prerequisites (like needing to know available type names from 'superset_advanced_data_type_list'), no indication of when this conversion is needed versus standard type conversion, and no discussion of error conditions or limitations. The agent receives no usage context beyond the basic function.
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 full burden for behavioral disclosure. It mentions making a PUT request to a specific API endpoint, which implies a write operation, but doesn't disclose critical traits: whether this requires authentication, what permissions are needed, if changes are reversible, rate limits, or error handling. The description adds minimal context beyond the basic update action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three clear sections: purpose statement, endpoint reference, and parameter/return explanations. Every sentence adds value, though the endpoint detail could be considered slightly technical. The structure is front-loaded with the core purpose, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, 0% schema description coverage, no output schema, and nested objects in parameters, the description is incomplete. It lacks information about authentication requirements, error responses, what happens to unspecified fields during update, and the structure of the returned dictionary. For a tool that modifies data, this creates significant uncertainty for an agent.
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 schema provides no parameter documentation. The description compensates by explaining that 'dashboard_id' is the ID to update and 'data' can include specific fields like dashboard_title, slug, owners, position, and metadata. However, it doesn't provide format details, constraints, or examples for these fields, leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'existing dashboard', making the purpose specific and understandable. It distinguishes from sibling tools like superset_dashboard_create and superset_dashboard_delete by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from superset_chart_update or other update tools in the sibling list.
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. It doesn't mention prerequisites (e.g., needing an existing dashboard ID), compare with superset_dashboard_create for new dashboards, or explain when to use superset_dashboard_update versus superset_chart_update for related components. 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.
Behavior2/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 mentions the API endpoint but lacks critical behavioral details: it doesn't specify if this is a read-only operation, whether it requires authentication, potential rate limits, error conditions, or pagination. The description is minimal beyond the basic action, leaving gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose, endpoint, and parameter/return details. It's front-loaded with the core action. However, the 'Args' and 'Returns' sections could be integrated more smoothly, and some sentences are slightly verbose (e.g., 'for databases that support catalogs'), keeping it from a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the basic action and parameter but lacks behavioral context (e.g., safety, errors) and doesn't fully explain the return value beyond 'dictionary with list of catalog names'. For a simple read tool, this is adequate but minimal.
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 schema provides no parameter details. The description adds minimal value by stating 'database_id: ID of the database', which clarifies the parameter's purpose but doesn't explain format, constraints, or where to obtain it. This partial compensation justifies a baseline 3, as it addresses the parameter's role without full semantics.
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 verb 'Get' and resource 'all catalogs from a database', making the purpose unambiguous. It distinguishes from siblings like 'superset_database_get_tables' by focusing on catalogs rather than tables or schemas. However, it doesn't explicitly differentiate from all database-related siblings, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid database ID), nor does it compare with siblings like 'superset_database_schemas' or 'superset_database_get_tables' for related data retrieval. Usage is implied but not explicitly 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 behavioral disclosure. It states the tool makes an API request and returns a dictionary, but it doesn't cover critical aspects like authentication requirements, rate limits, error handling, or whether the operation is read-only or has side effects. For a tool with no annotations, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise and well-structured. It starts with a clear purpose statement, followed by implementation details and parameter/return explanations in a bullet-like format. Each sentence adds value without redundancy, making it easy to parse. However, the inclusion of the API endpoint path ('/api/v1/database/{id}/connection') might be slightly verbose for an agent-focused description.
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 lack of annotations and output schema, the description is incomplete for effective tool use. It mentions returning 'a dictionary with detailed connection information' but doesn't specify what that includes (e.g., keys, data types). For a tool with no structured output and minimal behavioral context, more details on response structure, error cases, or usage examples would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics beyond the input schema. It explains that 'database_id' is the 'ID of the database,' which aligns with the schema's title 'Database Id' and type 'integer.' With 0% schema description coverage, the description partially compensates by clarifying the parameter's purpose, but it doesn't provide additional details like format examples or constraints, leaving room for improvement.
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: 'Get database connection information' and 'retrieve connection details for a specific database.' It specifies the verb ('get', 'retrieve') and resource ('database connection information'), making the action clear. However, it doesn't explicitly distinguish this tool from siblings like 'superset_database_get_by_id' or 'superset_database_test_connection', which might have overlapping purposes.
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. It mentions retrieving connection details but doesn't specify use cases, prerequisites, or comparisons to sibling tools such as 'superset_database_get_by_id' (which might return general database info) or 'superset_database_test_connection' (which might test connectivity). Without such context, an agent lacks direction on appropriate 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 full burden for behavioral disclosure. It states the tool 'verifies if the provided connection details can successfully connect' which implies a read-only, non-destructive test operation. However, it doesn't disclose authentication requirements, rate limits, error handling, or what constitutes 'successful' connection (e.g., timeout thresholds, permission checks). The description is minimal beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences: purpose statement, endpoint reference, and parameter/return overview. It's front-loaded with the core function. The 'Args:' and 'Returns:' sections add structure, though they could be integrated more smoothly. No wasted sentences, though slightly formulaic.
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 1 parameter (nested object), 0% schema coverage, no annotations, and no output schema, the description provides minimal but functional coverage. It explains what the tool does and the parameter's general content, but lacks details on connection detail structure, authentication needs, error cases, or return value specifics. It's adequate for basic understanding but incomplete for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds that 'database_data' includes 'sqlalchemy_uri and other parameters', giving some semantic context beyond the bare schema. However, it doesn't detail what 'other parameters' might be, their formats, or required fields. With 1 parameter but poor schema coverage, this provides basic but incomplete compensation.
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: 'Test a database connection' and specifies it makes a request to a specific API endpoint. It distinguishes from siblings like 'superset_database_create' or 'superset_database_update' by focusing on testing rather than creating/modifying. However, it doesn't explicitly contrast with 'superset_database_validate_parameters' which might be a closer alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing valid connection details), when testing is appropriate (e.g., before creating a database), or differentiate from similar tools like 'superset_database_validate_parameters'. Usage is implied but not explicitly 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. It mentions the tool makes an API request and validates parameters without creating a connection, which gives some behavioral context. However, it lacks details on authentication requirements, rate limits, error handling, or what specific validation checks are performed. For a validation tool with zero 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.
Conciseness4/5
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 additional context. It uses three sentences total with no wasted words. However, the structure could be slightly improved by integrating the Args and Returns sections more seamlessly, but it's still efficient.
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's complexity (validation operation with nested object parameter), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't detail the parameter structure, validation criteria, or return format beyond 'a dictionary with validation results.' For a tool that could involve sensitive connection data, more context is needed.
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 schema provides no parameter details. The description adds minimal value: it states 'parameters: Connection parameters to validate' but doesn't explain what these parameters are (e.g., host, port, credentials), their format, or constraints. This fails to compensate for the coverage gap, leaving the single parameter largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Validate database connection parameters' and specifies it 'makes a request to the /api/v1/database/validate_parameters/ endpoint to verify if the provided connection parameters are valid without creating a connection.' This is specific (verb+resource+scope) and distinguishes it from sibling tools like superset_database_test_connection or superset_database_create. However, it doesn't explicitly differentiate from all siblings, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it validates parameters 'without creating a connection,' which suggests it's for pre-checking before actual database operations. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like superset_database_test_connection or superset_database_create, nor does it mention prerequisites or exclusions. This is typical implied 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?
No annotations are provided, so the description carries full burden. It states the tool 'check[s] if the provided SQL is valid' but doesn't disclose behavioral traits like whether this is a read-only operation (implied by 'validate'), potential side effects (e.g., if validation runs queries), authentication needs, rate limits, or error handling. The description is minimal and misses key operational details 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose clearly. The subsequent sentences add endpoint and parameter details without redundancy. It uses a structured format with 'Args:' and 'Returns:' sections, though the return description is vague ('A dictionary with validation results'). Overall efficient with minimal waste.
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 no annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers basic purpose and parameters but lacks behavioral context (e.g., safety, auth), detailed usage guidelines, and specifics on return values. For a validation tool with 2 parameters and no structured support, more comprehensive information is needed to guide an AI agent effectively.
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 schema provides no parameter descriptions. The description adds basic semantics: 'database_id: ID of the database' and 'sql: SQL query to validate', which clarifies what each parameter represents. However, it doesn't provide format details (e.g., SQL dialect, database ID source) or constraints, leaving gaps. With 2 parameters and some value added, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Validate arbitrary SQL against a database' with specific verbs ('validate', 'check') and resources ('SQL', 'database'). It distinguishes from siblings like superset_database_test_connection (connection testing) and superset_sqllab_execute_query (actual execution), though not explicitly named. However, it doesn't fully differentiate from superset_database_validate_parameters (parameter validation), which is a minor gap.
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 on when to use this tool versus alternatives. It mentions the endpoint but doesn't specify scenarios like pre-execution validation, syntax checking, or when to choose this over other validation tools like superset_database_validate_parameters. The description lacks context about prerequisites or typical use cases.
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 states the tool stores data 'temporarily,' which is useful context about persistence. However, it lacks details on authentication needs, rate limits, error handling, or what 'temporarily' means (e.g., duration). For a creation tool with zero 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.
Conciseness4/5
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, followed by endpoint details and parameter/return explanations. Each sentence adds value without redundancy. It could be slightly more structured but is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creation operation with nested parameters, no annotations, no output schema), the description is minimally adequate. It covers the purpose, parameter semantics, and return value, but lacks behavioral details and usage guidelines. For a tool with no structured support, it meets the basic threshold but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning beyond the schema: it specifies that 'form_data' includes 'datasource, metrics, and visualization settings.' However, with schema description coverage at 0% and a single parameter that is a nested object, this explanation is minimal. It provides basic semantics but doesn't fully compensate for the lack of schema details, aligning with the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create form data for chart exploration' and 'store chart configuration data temporarily.' It specifies the verb (create/store) and resource (form data for chart exploration). However, it doesn't explicitly differentiate from its sibling 'superset_explore_form_data_get' beyond the create vs. get distinction, which is why it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the endpoint but doesn't explain the context, prerequisites, or when to choose this over other chart-related tools like 'superset_chart_create' or 'superset_explore_permalink_create.' This leaves the agent without usage direction.
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 full burden. It mentions the POST endpoint and that it 'generates a shareable link,' but lacks critical behavioral details: whether authentication is required, rate limits, error conditions, if the link is permanent or expires, or what 'state' must include. For a creation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose. It uses three sentences efficiently: stating the action, endpoint, and parameter/return details. No wasted words, though it could be slightly more detailed without losing conciseness.
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 creates a permalink (a write-like operation) with no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover authentication needs, error handling, link format, or what the returned dictionary contains. For a tool with this complexity and lack of structured data, more context is needed to be fully helpful.
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 adds that 'state' includes 'form_data' and is for 'chart exploration state,' providing some meaning beyond the generic schema. However, with 1 parameter and nested objects, more detail on the structure or examples would be helpful. The description partially compensates but doesn't fully bridge the coverage 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 states the tool's purpose: 'Create a permalink for chart exploration' and specifies it makes a POST request to generate a shareable link. It distinguishes from sibling tools like superset_explore_permalink_get (which retrieves rather than creates), but doesn't explicitly contrast with all siblings. The purpose is specific but could be more distinctive.
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 on when to use this tool versus alternatives is provided. The description mentions the endpoint but doesn't explain prerequisites, when this is appropriate versus other sharing methods, or what happens if the state is invalid. Usage is implied through the action described, but no contextual boundaries are set.
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 states the tool retrieves data via an API endpoint, implying a read-only operation, but doesn't specify authentication requirements, rate limits, error handling, or whether it's idempotent. For a tool with zero annotation coverage, this is insufficient to inform safe and effective use.
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 well-structured and concise, with a clear purpose statement followed by API endpoint details, args, and returns. Each sentence adds value without redundancy. It could be slightly more front-loaded by emphasizing the retrieval action earlier, but overall it's efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameter but lacks behavioral context, usage guidelines, and output details. Without annotations or an output schema, the agent must infer missing information, making this description incomplete for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description compensates by explaining the single parameter: 'key: Key of the permalink to retrieve.' This adds meaning beyond the schema's basic type definition. However, it doesn't provide examples, format details, or constraints (e.g., where the key comes from), leaving some ambiguity. With one parameter and partial compensation, a baseline 3 is appropriate.
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: 'Get a permalink for chart exploration' and 'retrieve a previously saved exploration state.' It specifies the verb ('Get', 'retrieve'), resource ('permalink', 'exploration state'), and scope ('previously saved'), making it unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'superset_explore_permalink_create', which is a minor gap.
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. It mentions retrieving a 'previously saved exploration state' but doesn't clarify prerequisites (e.g., needing a saved permalink first) or compare it to related tools like 'superset_explore_form_data_get'. This leaves the agent without context for tool selection.
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 full burden for behavioral disclosure. It states the tool makes an API request to download results, which implies a read operation, but doesn't clarify if this requires specific permissions, rate limits, or side effects (e.g., if it consumes query results or leaves them intact). It mentions returns 'a dictionary with the exported data or error information', adding some context on output behavior, but lacks details on error conditions or data format beyond CSV.
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 well-structured and appropriately sized. It starts with a clear purpose statement, followed by implementation details and parameter/return documentation. Each sentence adds value without redundancy. Minor improvement could be made by integrating the 'Args' and 'Returns' more seamlessly, but overall it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (exporting query results), no annotations, no output schema, and low schema coverage, the description is partially complete. It covers the basic purpose, parameter, and return type, but lacks context on prerequisites (e.g., needing an executed query), error handling, or comparison to siblings. For a tool that interacts with query results, more guidance on workflow integration would be beneficial.
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 description coverage is 0%, but the description includes an 'Args' section that documents the single parameter 'client_id' as 'Client ID of the query'. This adds meaningful semantics beyond the schema's basic type information. However, it doesn't explain how to obtain or validate the client_id, or what format it expects, leaving some gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Export the results of a SQL query to CSV'. It specifies the verb ('Export') and resource ('results of a SQL query'), and mentions the output format ('CSV'). However, it doesn't explicitly differentiate from sibling tools like 'superset_sqllab_get_results' which might retrieve results without exporting, leaving some ambiguity about when to choose this specific export tool.
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. It doesn't mention prerequisites (e.g., that a query must already be executed with a client_id), nor does it compare to siblings like 'superset_sqllab_get_results' for non-export retrieval. The only implied context is the need for a client_id, but this is covered in parameters, not usage scenarios.
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 full burden. It states it 'retrieves information' (implying read-only) and mentions the API endpoint, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what 'details' include. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by API endpoint details and parameter/return info. Each sentence adds value without redundancy. It could be slightly more structured but remains efficient with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and no output schema or annotations, the description is minimally complete. It covers the basic purpose and parameter semantics but lacks details on authentication, error cases, or return structure ('dictionary with tag details' is vague). For a simple read tool, it's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds minimal semantics: 'tag_id: ID of the tag to retrieve' clarifies the parameter's purpose beyond the schema's type/requirement. However, it doesn't explain format constraints (e.g., integer range) or provide examples, resulting in a baseline 3 as it adds some value but not fully.
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: 'Get details for a specific tag' with the verb 'Get' and resource 'tag'. It distinguishes from siblings like 'superset_tag_list' (list all tags) and 'superset_tag_create/delete' (mutations), though not explicitly mentioned. However, it doesn't fully differentiate from 'superset_tag_objects' which might retrieve related objects, keeping it at 4.
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 on when to use this tool versus alternatives is provided. The description mentions retrieving information about a specific tag, but doesn't specify prerequisites (e.g., needing a valid tag ID) or contrast with siblings like 'superset_tag_list' for bulk retrieval. Usage is implied from the purpose, but lacks explicit context.
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 states the action ('terminate a query') and mentions the API endpoint, but lacks critical details like required permissions, whether this is a destructive operation, error handling, or rate limits. This is inadequate for a mutation tool with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear title-like statement followed by brief implementation details and parameter/return explanations. Every sentence adds value, though the API endpoint detail could be considered slightly extraneous for an agent's decision-making.
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 this is a mutation tool with no annotations, no output schema, and low schema description coverage, the description is incomplete. It lacks information about side effects, error cases, authentication requirements, and what the return dictionary contains, making it insufficient for safe and effective use.
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 adds meaningful context for the single parameter ('client_id: Client ID of the query to stop'), which is valuable since schema description coverage is 0%. It clarifies what the parameter represents, though it doesn't specify format or sourcing details. For a tool with only one parameter, this provides sufficient semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('stop') and resource ('a running query'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'superset_sqllab_execute_query' or 'superset_query_get_by_id', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It doesn't mention prerequisites (e.g., needing a running query first) or compare it to other query-related tools in the sibling list, leaving the agent to infer usage context.
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 full burden. It mentions the endpoint ('/api/v1/log/recent_activity/') and return format ('dictionary with recent user activities'), but lacks critical behavioral details: authentication requirements, rate limits, pagination, data freshness, or what happens if no recent activity exists. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences: purpose statement, endpoint detail, and return format. It's front-loaded with the core function. Minor improvements could include combining sentences or removing the endpoint detail if not critical for agent use, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers what the tool does and what it returns, but lacks context about authentication, data scope, or error handling. Without annotations or output schema, the description should ideally provide more behavioral context to be fully complete for agent use.
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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter semantics, but it correctly implies no parameters are required by not mentioning any. Baseline for 0 parameters is 4, as the description doesn't contradict or add unnecessary detail.
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: 'Get recent activity data for the current user' and specifies it retrieves 'a history of actions performed by the current user.' It distinguishes itself from sibling tools by focusing on user activity logs rather than charts, dashboards, databases, or other resources. However, it doesn't explicitly differentiate from potential similar activity-tracking tools (none exist in siblings).
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. It doesn't mention prerequisites (e.g., authentication status), time ranges, or limitations compared to other logging tools. The sibling list includes no other activity-related tools, but the description fails to specify if this is the only way to access user activity or if there are context-specific considerations.
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 mentions the endpoint ('/api/v1/advanced_data_type/types') and return format ('A dictionary with available advanced data types and their configurations'), which adds some behavioral context. However, it lacks critical details like authentication requirements, rate limits, error handling, or whether this is a read-only operation (implied but not stated). For a tool with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences: purpose, endpoint details, and return format. Each sentence adds value without redundancy. It's front-loaded with the core purpose. Minor improvement could be made by integrating the endpoint detail more seamlessly, 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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers what the tool does and what it returns, but lacks context on authentication, error cases, or integration with sibling tools. Without annotations or output schema, more behavioral detail would be helpful for completeness, though the low complexity mitigates this gap.
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 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to explain parameters, so it meets the baseline of 4 for zero-parameter tools. No additional parameter semantics are required or 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: 'Get list of available advanced data types' with the specific verb 'Get' and resource 'advanced data types'. It distinguishes from the sibling 'superset_advanced_data_type_convert' by focusing on listing rather than conversion. However, it doesn't explicitly differentiate from other list tools like 'superset_dataset_list' or 'superset_tag_list' beyond the resource specificity.
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. It doesn't mention prerequisites (e.g., authentication), typical use cases, or relationships with sibling tools like 'superset_advanced_data_type_convert'. The agent must infer usage from the name and description alone without explicit context.
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 full burden for behavioral disclosure. It mentions the API endpoint ('/api/v1/chart/ POST'), implying a write operation, but doesn't specify authentication requirements, rate limits, error conditions, or what happens on failure. It states the return format ('dictionary with created chart information'), but lacks details on response structure or side effects. For a creation tool with zero annotation coverage, this leaves significant 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?
The description is well-structured with a clear purpose statement, API endpoint detail, and organized parameter explanations. It uses bullet-like formatting for Args and Returns sections, making it scannable. However, the API endpoint sentence is somewhat redundant with the purpose, and the parameter descriptions could be more concise (e.g., combining datasource_id and datasource_type). Overall, it's efficient but not perfectly tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested object, no output schema, no annotations), the description is moderately complete. It covers all parameters and the return type, but lacks authentication requirements, error handling, and detailed behavioral context. Without annotations or output schema, the agent must infer missing operational details. It's adequate for basic use but insufficient for robust integration.
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 provides meaningful explanations for all 5 parameters: slice_name ('Name/title of the chart'), datasource_id ('ID of the dataset or SQL table'), datasource_type ('Type of datasource'), viz_type ('Visualization type'), and params ('Visualization parameters including metrics, groupby, time_range, etc.'). This adds crucial context beyond the bare schema, though it could elaborate on param object structure or provide examples for viz_type.
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 action ('Create a new chart') and resource ('in Superset'), making the purpose immediately understandable. It distinguishes from siblings like superset_chart_list, superset_chart_update, and superset_chart_delete by specifying creation rather than retrieval, modification, or deletion. However, it doesn't explicitly contrast with superset_dashboard_create or other visualization creation tools, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It doesn't mention prerequisites (e.g., needing authentication, existing datasets), when not to use it (e.g., for updating existing charts), or direct alternatives among the many sibling tools like superset_dashboard_create or superset_saved_query_create. The agent must infer usage from context 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the API endpoint and return format, but lacks details on authentication needs, rate limits, error handling, or whether it's a read-only operation. For a tool with zero annotation coverage, this is insufficient to fully inform the agent about 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with a clear purpose statement, endpoint details, and parameter/return explanations in separate sections. It avoids redundancy and uses minimal sentences to convey essential information, though the endpoint detail could be considered slightly verbose for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is moderately complete. It covers the basic purpose, parameter, and return format, but lacks behavioral details like authentication or error handling. Without annotations or output schema, it provides a baseline but misses some contextual depth needed for optimal agent use.
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 adds meaningful context for the single parameter 'database_id' by explaining it's the 'ID of the database', which clarifies its purpose beyond the schema's basic type (integer). With 0% schema description coverage and only one parameter, this compensation is effective, though it doesn't detail format constraints (e.g., valid ID ranges).
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: 'Get a list of tables for a given database.' It specifies the verb ('Get') and resource ('tables'), and distinguishes it from siblings like 'superset_database_get_catalogs' or 'superset_database_schemas' by focusing on tables. However, it doesn't explicitly differentiate from potential similar tools beyond the name, keeping it at a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the endpoint but doesn't compare it to siblings like 'superset_database_list' or 'superset_database_get_by_id', nor does it specify prerequisites or exclusions. This lack of contextual advice limits its utility 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.
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 mentions the API endpoint and that it updates properties, but doesn't cover critical aspects like authentication requirements, error handling, whether changes are reversible, rate limits, or what happens to unspecified properties. This is a significant gap 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 efficiently structured with a clear purpose statement, API endpoint detail, and separate Args/Returns sections. Every sentence adds value, though the API endpoint detail could be considered slightly technical for some users.
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 mutation tool with 2 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and parameters but lacks behavioral context, error information, and detailed output expectations. The absence of annotations increases the burden on the description, which it doesn't fully meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining both parameters: 'database_id' is identified as the ID to update, and 'data' is described as including specific fields like database_name, sqlalchemy_uri, password, and extra configs. This adds meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update an existing database connection') and resource ('database connection properties'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like superset_database_create or superset_database_delete, which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It doesn't mention prerequisites (e.g., needing an existing database ID), when not to use it, or how it differs from related tools like superset_database_create or superset_database_validate_parameters.
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 full burden. It mentions that it 'runs a SQL query' and returns 'results or execution status for async queries', which hints at mutation (execution) and possible async behavior. However, it lacks critical details: whether it's read-only or modifies data, authentication requirements, rate limits, error handling, or what 'async queries' entail. For a tool that executes arbitrary SQL with no safety annotations, 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.
Conciseness4/5
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, followed by implementation details and parameter explanations. Each sentence adds value, with no redundant information. It could be slightly more structured (e.g., bullet points), but it's efficient overall.
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 complexity (SQL execution tool with potential data mutation), no annotations, no output schema, and 2 parameters, the description is minimally adequate. It covers the basic purpose and parameters but lacks critical context: no output details (beyond 'dictionary'), no error information, no async behavior explanation, and no safety warnings. It meets the bare minimum but leaves significant gaps for an agent to operate safely.
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 adds meaning by explaining 'database_id: ID of the database to query' and 'sql: SQL query to execute', which clarifies the purpose of each parameter beyond their schema titles ('Database Id', 'Sql'). However, it doesn't provide format examples (e.g., SQL syntax, database ID sources) or constraints, so it's not a full 5.
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: 'Execute a SQL query in SQL Lab' specifies the verb (execute) and resource (SQL query in SQL Lab). It distinguishes from siblings like 'superset_sqllab_format_sql' (which formats rather than executes) and 'superset_sqllab_estimate_query_cost' (which estimates rather than executes). However, it doesn't explicitly mention how it differs from all siblings, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication, database availability), when to choose it over other query tools like 'superset_database_validate_sql', or any constraints (e.g., query size limits, async vs sync). The agent must infer usage from the name and context 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool formats SQL for readability via an API endpoint, implying a read-only, non-destructive operation. However, it lacks details on rate limits, authentication needs, error handling, or what 'standard formatting rules' entail (e.g., indentation, capitalization). 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.
Conciseness4/5
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 implementation details and parameter/return info. Each sentence adds value without redundancy. It could be slightly more concise by merging some lines, but overall it's efficient with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally complete. It covers the basic purpose, parameter meaning, and return type. However, for a tool with no annotations and no output schema, it should ideally include more behavioral context (e.g., what the formatted output looks like, any limitations). It's adequate but has clear gaps in fully informing the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema. With 0% schema description coverage (the schema only has a generic 'sql' parameter with no details), the description specifies that 'sql' is the 'SQL query to format,' clarifying its purpose. Since there's only one parameter, the description adequately compensates for the low schema coverage, though it could provide more on format constraints (e.g., SQL dialect).
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: 'Format a SQL query for better readability' and 'apply standard formatting rules to the provided SQL query.' This specifies the verb (format) and resource (SQL query) with the goal of improved readability. However, it doesn't explicitly differentiate from potential siblings like 'superset_database_validate_sql' which might also process SQL queries, though the formatting focus is distinct.
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. It mentions the endpoint but doesn't specify scenarios (e.g., before execution, for debugging, or for presentation) or prerequisites. With many sibling tools related to SQL processing (e.g., 'superset_sqllab_execute_query', 'superset_database_validate_sql'), there's no explicit comparison or exclusion 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?
No annotations are provided, so the description carries the full burden. It mentions making a request to an API endpoint and returning a dictionary with id and name, which adds some context. However, it lacks critical behavioral details: whether this is a read-only operation, if it requires authentication, potential rate limits, error handling, or pagination for large tag lists. For a tool with zero 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.
Conciseness4/5
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. The second sentence adds implementation detail (API endpoint), and the third describes the return value. Each sentence adds value without redundancy, though the structure could be slightly more polished (e.g., merging sentences).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does and the return format, but it lacks behavioral context (e.g., authentication needs, error cases). For a simple read operation, this is passable but leaves gaps that could hinder agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). With no parameters, the baseline is 4, as there's nothing to document. The description doesn't need to add parameter semantics, and it doesn't introduce any confusion about inputs.
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: 'Get a list of tags from Superset' (verb+resource). It specifies retrieving 'all tags defined in the Superset instance,' which distinguishes it from sibling tools like superset_tag_get_by_id (which gets a specific tag). However, it doesn't explicitly differentiate from superset_tag_objects, which might also list tags with objects, making it slightly less specific than a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like superset_tag_get_by_id (for a single tag) or superset_tag_objects (for tags with objects), nor does it specify prerequisites (e.g., authentication). This leaves the agent to infer usage from context 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While it indicates this is a mutation operation ('remove'), it doesn't specify whether this requires specific permissions, what happens if the tag doesn't exist on the object, whether the operation is reversible, or any rate limits. The description mentions a return value but doesn't describe potential error responses or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, action, Args, Returns) and uses minimal sentences. Each sentence serves a purpose, though the second sentence ('Makes a request to...') is somewhat redundant with the first and could be eliminated for even better conciseness.
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 mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description provides basic but incomplete context. It covers the core operation and parameters adequately but lacks important behavioral details like error handling, authentication requirements, and what constitutes valid object_type values beyond the examples given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides essential semantic context for all three parameters through the Args section. It clarifies what each parameter represents (object type, object ID, tag name) and provides examples for object_type. This significantly compensates for the lack of schema descriptions, though it doesn't specify format constraints or valid values beyond the examples.
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 action ('Remove a tag from an object') and specifies the resource ('tag association from a specific object'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'superset_tag_object_add' or other tag-related tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 'superset_tag_delete' or 'superset_tag_object_add'. There's no mention of prerequisites, error conditions, or appropriate contexts for untagging operations, leaving the agent with insufficient usage context.
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 states the tool retrieves data (implying read-only) and returns a dictionary grouped by tag, but lacks details on permissions, rate limits, error handling, or whether it's idempotent. The description adds some context about the return format but is insufficient for a mutation-free tool with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the core purpose, mentions the API endpoint, and describes the return value. Each sentence adds value without redundancy. However, it could be slightly more front-loaded by leading with the return format for clarity.
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 0 parameters, no annotations, and no output schema, the description is minimally adequate. It explains what the tool does and the return format, but lacks behavioral details like pagination, authentication needs, or error cases. For a simple retrieval tool, it meets basic needs but leaves gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention any parameters, which is appropriate. It adds value by explaining the return structure ('dictionary with tagged objects grouped by tag'), compensating for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get objects associated with tags' and 'retrieve all objects that have tags assigned to them.' It specifies the verb ('get', 'retrieve') and resource ('objects associated with tags'), but does not explicitly differentiate it from sibling tools like 'superset_tag_list' or 'superset_tag_get_by_id', which focus on tags themselves rather than tagged objects.
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. It mentions the API endpoint but does not specify use cases, prerequisites, or exclusions. For example, it does not clarify if this is for bulk retrieval or how it differs from other tag-related tools like 'superset_tag_object_add' or 'superset_tag_object_remove'.
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 full burden but offers minimal behavioral insight. It mentions the API endpoint and return type ('A dictionary with user role information'), but lacks details on authentication requirements, error handling, rate limits, or whether this is a read-only operation. The phrase 'Get roles for the current user' implies a read operation, but this isn't explicitly stated.
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 well-structured and concise, with three sentences that each add value: stating the purpose, specifying the API endpoint, and describing the return type. There's no wasted text, though it could be slightly more front-loaded by integrating the return info earlier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no parameters and no output schema, the description is adequate but incomplete. It covers the basic purpose and return format, but lacks context on authentication needs, error cases, or how the returned dictionary is structured. Without annotations or output schema, more behavioral detail would improve completeness.
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 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain parameters, so it appropriately avoids redundant information. A baseline of 4 is applied since no parameters exist to document.
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: 'Get roles for the current user' specifies the verb (get) and resource (roles), and 'Makes a request to the /api/v1/me/roles/ endpoint' provides implementation context. However, it doesn't explicitly differentiate from sibling tools like 'superset_user_get_current', which might retrieve different user information.
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 doesn't mention prerequisites (e.g., authentication), compare it to similar tools like 'superset_user_get_current', or specify scenarios where retrieving user roles is appropriate versus other user-related operations.
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 mentions the API endpoint and return format, but lacks critical details such as authentication requirements, rate limits, error handling, or whether this is a read-only operation (though implied by 'Get'). For a tool with zero 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.
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, followed by API details and parameter/return explanations. Every sentence adds value without redundancy, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description covers the basics adequately. However, it lacks completeness for real-world use, such as authentication needs, error cases, or pagination details, which are important for a tool interacting with a database API.
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 adds meaningful context for the single parameter 'database_id', explaining it as the 'ID of the database', which clarifies its purpose beyond the schema's basic type (integer). With 0% schema description coverage and only one parameter, this compensation is adequate, though it could benefit from examples or format details.
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 with a specific verb ('Get') and resource ('schemas for a specific database'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'superset_database_get_tables' or 'superset_database_get_catalogs', which might retrieve related but different database metadata.
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. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools like 'superset_database_get_tables' or 'superset_database_get_catalogs', leaving the agent with no usage direction beyond the basic purpose.
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 full burden. It mentions the API endpoint '/api/v1/dataset/{id}' which adds implementation context, and states it 'retrieves detailed information including columns and metrics', giving some behavioral insight. However, it doesn't disclose important traits like whether this is a read-only operation (implied but not stated), authentication requirements, error handling, or rate limits. For a tool with no annotations, this leaves significant 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?
The description is appropriately sized with three clear sections: purpose statement, implementation detail, and parameter/return documentation. It's front-loaded with the core purpose. The Args/Returns structure is helpful, though slightly verbose for a single parameter. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and no output schema, the description provides basic purpose and parameter semantics but lacks comprehensive context. It doesn't explain the return structure beyond 'dictionary with complete dataset information', doesn't mention error cases, and with no annotations, leaves behavioral aspects underspecified. For a simple read operation, it's minimally adequate but incomplete.
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 the parameter 'dataset_id' with explanation 'ID of the dataset to retrieve', which provides semantic meaning beyond the schema's basic 'integer' type. However, with 0% schema description coverage and only 1 parameter, this minimal addition meets the baseline. It doesn't elaborate on ID format, sourcing, or validation, leaving room for improvement.
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: 'Get details for a specific dataset' with the specific resource 'dataset' and verb 'get details'. It distinguishes from siblings like 'superset_dataset_list' (which lists datasets) and 'superset_dataset_create' (which creates datasets). However, it doesn't explicitly mention what 'details' include beyond 'columns and metrics' in the second sentence.
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 through 'specific dataset' and the parameter 'dataset_id', suggesting this is for retrieving details of a known dataset. However, it doesn't explicitly state when to use this versus alternatives like 'superset_dataset_list' for browsing datasets or other get_by_id tools for different resources. No explicit when-not-to-use guidance is provided.
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 states this is a retrieval operation ('get'), implying it's likely read-only, but doesn't disclose behavioral traits such as authentication requirements, error handling (e.g., what happens if the key is invalid), rate limits, or response format details beyond 'a dictionary.' This leaves significant gaps for an AI 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 well-structured and concise: it starts with a clear purpose, provides endpoint context, and includes separate 'Args' and 'Returns' sections. Every sentence adds value without redundancy, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameter semantics but lacks usage guidelines and behavioral details (e.g., auth, errors). Without annotations or output schema, it should do more to be fully helpful.
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 adds meaningful context for the single parameter 'key': it explains it's the 'Key of the form data to retrieve.' With 0% schema description coverage, this compensates well by clarifying the parameter's purpose, though it doesn't specify format (e.g., string pattern) or examples. For one parameter, this is sufficient.
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: 'Get form data for chart exploration' and 'retrieve previously stored chart configuration.' It specifies the verb ('get') and resource ('form data'), but doesn't explicitly differentiate it from sibling tools like 'superset_explore_form_data_create' or 'superset_explore_permalink_get' that might handle similar data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions retrieving 'previously stored' data but doesn't specify prerequisites (e.g., needing a valid key from a create operation) or contrast it with siblings like 'superset_explore_form_data_create' for storing data.
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 full burden for behavioral disclosure. It states this is a GET operation to retrieve information, implying it's read-only and non-destructive. However, it doesn't mention authentication requirements, rate limits, error conditions, or what happens if the chart ID doesn't exist. The endpoint reference adds some technical context but lacks operational details.
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 well-structured with clear sections: purpose statement, endpoint reference, Args, and Returns. Each sentence earns its place. However, the endpoint detail could be considered implementation-specific rather than user-focused, and the 'Returns' section could be more concise by just stating it returns complete chart information rather than specifying 'dictionary' format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with 1 parameter and no output schema, the description provides adequate basics: what it does, what parameter it needs, and what it returns. However, it lacks important context about authentication (all Superset tools typically require auth), error handling, and relationship to sibling tools. Without annotations or output schema, more behavioral context would be helpful.
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 adds meaningful context for the single parameter 'chart_id' by explaining it's 'ID of the chart to retrieve'. With 0% schema description coverage (the schema only has title 'Chart Id' and type 'integer'), this description provides essential semantic information that the schema lacks. For a single parameter tool, this is adequate compensation.
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: 'Get details for a specific chart' with the verb 'get' and resource 'chart'. It distinguishes from siblings like 'superset_chart_list' (list all charts) and 'superset_chart_create' (create new chart) by focusing on retrieving details for a specific ID. However, it doesn't explicitly mention how it differs from 'superset_dashboard_get_by_id' which serves a similar purpose for dashboards.
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 through the phrase 'specific chart' and mentions the endpoint '/api/v1/chart/{id}', suggesting it should be used when you have a chart ID. However, it provides no explicit guidance on when to use this vs. alternatives like 'superset_chart_list' for browsing charts or 'superset_dashboard_get_by_id' for dashboard details. No prerequisites or exclusions are mentioned.
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 full burden for behavioral disclosure. While it mentions this is an update operation and references the PUT endpoint, it doesn't disclose important behavioral aspects like authentication requirements, permission levels needed, whether the operation is idempotent, error conditions, or rate limits. The description provides basic operational context but lacks critical behavioral details 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 well-structured with clear sections: purpose statement, endpoint reference, Args section, and Returns section. It's appropriately sized at 4 sentences with zero wasted words. The information is front-loaded with the core purpose stated first. Minor improvement could be made by integrating the endpoint reference more seamlessly.
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 mutation tool with no annotations and no output schema, the description provides basic but incomplete context. It covers the purpose, parameters, and return type at a high level, but lacks important details about authentication, permissions, error handling, and what specific fields are updatable. The description is minimally adequate but leaves significant gaps for safe and effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining both parameters: 'chart_id: ID of the chart to update' and 'data: Data to update, can include slice_name, description, viz_type, params, etc.' It provides meaningful context about what the data parameter can contain, which is valuable beyond the bare schema. The description adds substantial semantic value for both 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?
The description clearly states the tool's purpose as 'Update an existing chart' with specific verb and resource. It distinguishes from sibling tools like superset_chart_create (creation) and superset_chart_delete (deletion), but doesn't explicitly differentiate from superset_dashboard_update which updates a different resource type. The description provides adequate clarity 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the mention of updating 'existing chart' and referencing the specific API endpoint. It doesn't provide explicit guidance on when to use this tool versus alternatives like superset_chart_create for new charts or superset_dashboard_update for dashboards. No prerequisites, exclusions, or comparative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the API endpoint ('/api/v1/dashboard/ POST') which is useful context, and states it 'creates a new dashboard' which implies a write/mutation operation. However, it doesn't disclose important behavioral traits like authentication requirements, error conditions, rate limits, or what happens on duplicate titles. The return format is mentioned but without structural details.
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 well-structured with clear sections (purpose, endpoint, args, returns) and uses bullet points effectively. Every sentence adds value: the first states the purpose, the second provides implementation context, and the parameter/return sections document essential information. It could be slightly more concise by combining some elements, 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?
For a creation tool with 2 parameters, no annotations, and no output schema, the description provides basic but incomplete coverage. It documents the parameters well and mentions the return type, but lacks crucial context about authentication, error handling, and behavioral constraints. Given the mutation nature of the operation and the complexity implied by 'json_metadata' (a nested object), more guidance would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the schema's lack of parameter documentation. It provides meaningful explanations for both parameters: 'dashboard_title: Title of the dashboard' and 'json_metadata: Optional JSON metadata for dashboard configuration, can include layout, color scheme, and filter configuration'. This adds substantial value beyond the bare schema, though it doesn't specify format constraints or examples.
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 'Create a new dashboard in Superset' which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'superset_dashboard_update' and 'superset_dashboard_delete' by focusing on creation. However, it doesn't explicitly differentiate from other creation tools like 'superset_chart_create' or 'superset_dataset_create' beyond the resource type.
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. It doesn't mention prerequisites (like authentication), when creation is appropriate versus updating existing dashboards, or how it relates to other dashboard operations like listing or getting by ID. 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.
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 discloses that the tool 'Makes a request to the /api/v1/menu/ endpoint,' which adds implementation context, and mentions the return format ('A dictionary with menu items and their configurations'). However, it lacks details on authentication requirements, rate limits, error handling, or whether the operation is idempotent—key behavioral traits for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, using three sentences that efficiently cover the tool's purpose, endpoint, and return value. Each sentence adds value without redundancy. It could be slightly more front-loaded by merging the first two sentences, but overall it's appropriately sized and wastes no 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?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but has gaps. It explains what the tool does and the return format, but without annotations or output schema, it should ideally include more behavioral context (e.g., authentication needs, error cases). The description is complete enough for basic understanding but lacks depth for robust agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and behavior. This aligns with the baseline expectation for zero-parameter tools, where the description needn't compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the Superset menu data' and 'retrieve the navigation menu structure based on user permissions.' It specifies the verb ('Get'), resource ('Superset menu data'), and scope ('based on user permissions'). However, it doesn't explicitly differentiate from sibling tools like 'superset_user_get_current' or 'superset_sqllab_get_bootstrap_data' which might also retrieve user-specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool. It mentions that the menu is 'based on user permissions,' which implies it's for accessing navigation data, but offers no explicit when-to-use rules, alternatives, or exclusions. For example, it doesn't clarify if this should be used for initial setup versus dynamic menu updates or how it relates to other data retrieval tools in the sibling list.
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 full burden for behavioral disclosure. It mentions the API endpoint and that it 'retrieves information about a saved SQL query,' which implies a read-only operation, but doesn't explicitly state this is a safe read operation. It lacks details about authentication requirements, rate limits, error conditions, or what happens if the query_id doesn't exist. The description adds some context about what information is returned but doesn't fully compensate for the lack of 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 appropriately sized with three clear sections: purpose statement, API endpoint context, and parameter/return documentation. Each sentence adds value without redundancy. The structure with 'Args:' and 'Returns:' headings is helpful, though the formatting could be slightly cleaner. There's no wasted verbiage.
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 single-parameter read operation with no annotations and no output schema, the description provides adequate basic information about what the tool does and what parameter it requires. However, it lacks details about authentication requirements, error handling, rate limits, and the complete structure of the returned dictionary. The mention of 'including SQL text and database' gives some output context but doesn't fully compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter: 'query_id: ID of the saved query to retrieve.' With schema description coverage at 0% (the schema only shows 'Query Id' as title with no description), this parameter documentation in the description is essential. It clarifies that this is an identifier for retrieving a specific saved query, though it doesn't specify format constraints or where to obtain valid IDs.
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 as 'Get details for a specific saved query' with the specific verb 'Get' and resource 'saved query'. It distinguishes from sibling tools like 'superset_saved_query_create' and 'superset_sqllab_get_saved_queries' by focusing on retrieving details for a single query by ID rather than creating or listing queries. However, it doesn't explicitly differentiate from 'superset_query_get_by_id' which appears to serve a similar purpose for different query types.
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 specifying it retrieves 'a specific saved query' and mentions the query_id parameter, suggesting this should be used when you have a known query ID. However, it provides no explicit guidance on when to use this versus alternatives like 'superset_query_get_by_id' or 'superset_sqllab_get_saved_queries', nor does it mention prerequisites 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: it specifies the API endpoint ('/api/v1/saved_query/'), mentions pagination, and notes access is limited to 'the current user has access to'. However, it doesn't cover critical aspects like authentication requirements, rate limits, error handling, or what 'access' entails (e.g., permissions). This is a moderate but incomplete effort.
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 well-structured and concise, with three sentences that each add value: stating the purpose, detailing the request and pagination, and describing the return format. There's no wasted text, and it's front-loaded with the core function. A minor deduction for slightly verbose phrasing like 'Makes a request to...' instead of a more direct statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with no parameters) and no annotations or output schema, the description is adequate but has gaps. It explains what the tool does, the endpoint, pagination, and return content, but lacks details on authentication, error cases, or pagination mechanics (e.g., how to navigate pages). This makes it minimally viable but not fully comprehensive.
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 0 parameters, and schema description coverage is 100% (though the schema is empty). The description doesn't need to explain parameters, so it appropriately focuses on behavior. It doesn't add param info beyond the schema, but with no parameters, this is acceptable, warranting a baseline score above 3.
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: 'Get a list of saved queries from SQL Lab.' It specifies the verb ('Get'), resource ('saved queries'), and scope ('from SQL Lab'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'superset_query_list' or 'superset_saved_query_get_by_id', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It mentions that results are paginated and the current user's access, but doesn't specify prerequisites, exclusions, or compare it to similar tools like 'superset_saved_query_get_by_id' or 'superset_query_list'. This leaves the agent without clear usage context.
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 states this 'creates an association' (implying a write/mutation operation) and returns a 'confirmation', but lacks critical behavioral details: required permissions, whether it's idempotent (e.g., if tag already exists), error handling (e.g., invalid object_id), or side effects. For a mutation tool with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized: a brief purpose statement, an explanatory sentence, and separate Args/Returns sections. Every sentence adds value (e.g., explaining the association creation). It could be slightly more front-loaded by moving the Args/Returns inline, 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.
Completeness3/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 (3 parameters, mutation operation) and lack of annotations/output schema, the description is partially complete. It covers parameters well and states the return type, but misses behavioral context (permissions, idempotency) and doesn't fully address when to use it. For a mutation tool with no structured support, this leaves gaps an agent would need to infer.
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 fully. It explicitly lists all three parameters (object_type, object_id, tag_name) with clear semantics: object_type examples ('chart', 'dashboard'), object_id as 'ID of the object', and tag_name as 'Name of the tag'. This adds essential meaning beyond the bare schema, effectively documenting all 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?
The description clearly states the action ('Add a tag to an object') and specifies the resource ('object' with examples like chart, dashboard). It distinguishes from sibling 'superset_tag_object_remove' by focusing on addition rather than removal. However, it doesn't explicitly differentiate from other tagging tools like 'superset_tag_create' or 'superset_tag_objects' beyond the specific add operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the tag or object must exist first), compare to sibling tools like 'superset_tag_object_remove' for removal, or specify use cases. 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.
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 mentions making an API request but doesn't describe authentication requirements, rate limits, error conditions, or what happens if the database ID is invalid. For a read operation with zero annotation coverage, this leaves significant 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?
The description is appropriately sized with four sentences that are front-loaded (purpose first, then implementation details, then parameter and return value documentation). The Args/Returns structure is clear, though slightly redundant with the opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, read-only operation), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and parameter but lacks behavioral context and usage guidance that would make it complete for effective agent use.
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 adds meaningful context for the single parameter 'database_id' by explaining it's 'ID of the database' and that the tool retrieves functions 'supported by the database.' With 0% schema description coverage, this compensates well for the schema's lack of parameter documentation, though it doesn't specify format constraints (e.g., integer type).
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 ('Get') and resource ('function names supported by a database'), and distinguishes it from siblings like superset_database_get_tables or superset_database_get_catalogs by focusing specifically on SQL functions rather than other database metadata.
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. It doesn't mention prerequisites (e.g., needing a valid database ID), typical use cases, or how it differs from related database metadata tools in the sibling list.
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 discloses the endpoint ('/api/v1/query/{id}') and that it retrieves 'detailed information,' which implies a read-only operation. However, it lacks details on authentication needs, rate limits, error handling, or what 'complete query execution information' entails, leaving behavioral gaps for the 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 well-structured and front-loaded with the core purpose, followed by endpoint details and clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and parameter semantics but lacks behavioral details like authentication or error handling. For a read operation with minimal structured data, it meets the minimum viable threshold but has clear 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 description adds meaningful context for the single parameter: 'query_id: ID of the query to retrieve.' Since schema description coverage is 0% (the schema only provides type and title), this compensates well by explaining the parameter's purpose. However, it does not specify ID format constraints or examples, preventing a perfect score.
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: 'Get details for a specific query' and 'retrieve detailed information about a specific query execution.' It specifies the verb ('get') and resource ('query'), but does not explicitly differentiate it from sibling tools like 'superset_query_list' or 'superset_saved_query_get_by_id' beyond the ID-based retrieval, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It mentions retrieving details for a 'specific query' by ID, but does not clarify scenarios for its use over other query-related tools (e.g., 'superset_query_list' for listing queries or 'superset_saved_query_get_by_id' for saved queries), leaving the agent to infer usage context.
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 full burden. It mentions the endpoint ('/api/v1/sqllab/') and return type ('A dictionary with SQL Lab configuration'), but fails to disclose critical behavioral traits: whether this requires authentication, rate limits, error handling, or if it's a read-only operation. For a tool with zero annotation coverage, this is insufficient, though it does add some context beyond the basic purpose.
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: the first sentence states the purpose, followed by endpoint details and return value. Every sentence adds value without redundancy, making it efficient and easy to parse. It appropriately balances brevity with necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with 0 params) and lack of annotations/output schema, the description is moderately complete. It explains what the tool does and what it returns, but misses behavioral details like authentication needs or error cases. Without an output schema, it should ideally describe the return structure more thoroughly, but the mention of 'dictionary with SQL Lab configuration' provides some context, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description correctly adds no parameter information, which is appropriate. Baseline for 0 params is 4, as it avoids unnecessary details and focuses on the tool's purpose and output.
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: 'Get the bootstrap data for SQL Lab' specifies the verb (get) and resource (bootstrap data for SQL Lab). It distinguishes from siblings like 'superset_sqllab_execute_query' or 'superset_sqllab_get_results' by focusing on configuration data rather than query execution or results. However, it doesn't explicitly contrast with all siblings, keeping it at 4 instead of 5.
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 stating it retrieves 'configuration data needed for the SQL Lab interface,' suggesting it should be used when setting up or initializing SQL Lab. However, it lacks explicit guidance on when to use this versus alternatives (e.g., other SQL Lab tools) or any prerequisites, such as authentication requirements. This makes it adequate but with gaps.
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 states this is a POST request to create a tag, implying a write operation, but lacks details on permissions required, error conditions, rate limits, or whether the operation is idempotent. The description adds minimal context beyond the basic action, leaving significant behavioral aspects undocumented.
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 well-structured and appropriately sized, with a clear purpose statement, endpoint details, and separate sections for arguments and returns. It avoids unnecessary fluff, though the endpoint detail could be considered slightly technical. Every sentence adds value, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a simple create operation with one parameter) and the absence of annotations and output schema, the description is moderately complete. It covers the purpose, parameter semantics, and return type, but lacks behavioral details like error handling or permissions. For a mutation tool with no structured support, it meets minimum viability but has 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains the 'name' parameter as 'Name for the tag', adding semantic meaning beyond the schema, which has 0% description coverage and only provides a title. This compensates well for the low schema coverage, though it does not detail constraints like length or allowed characters. With only one parameter, this is sufficient for clarity.
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 specific action ('Create a new tag in Superset') and identifies the resource ('tag'), distinguishing it from sibling tools like superset_tag_delete, superset_tag_get_by_id, and superset_tag_list. It explicitly mentions the POST endpoint and the purpose of tagging objects like charts and dashboards, providing a complete and specific purpose statement.
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. It does not mention prerequisites (e.g., authentication), compare it to sibling tools like superset_tag_list or superset_tag_delete, or specify scenarios where tag creation is appropriate. Usage is implied only by the action of creating a tag, with no explicit context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a POST endpoint (implying a write operation) and describes the return format, which adds value. However, it doesn't mention authentication requirements, error handling, rate limits, or whether the operation is idempotent, leaving behavioral gaps 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 well-structured with clear sections (purpose, args, returns) and uses bullet points for readability. It's appropriately sized but could be slightly more concise by integrating the purpose and endpoint details. Every sentence adds value, 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?
Given no annotations, no output schema, and a mutation tool with nested parameters, the description is moderately complete. It covers the purpose, parameter details, and return format, but lacks information on authentication, error cases, or sibling tool relationships. For a create operation, more behavioral context would improve completeness.
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 provides detailed semantics for the single parameter 'query_data', listing its dictionary contents (db_id, schema, sql, label, description) with notes on optional fields. This adds significant meaning beyond the bare schema, fully documenting the parameter structure.
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 creates a new saved query, specifying the verb 'create' and resource 'saved query'. It distinguishes from siblings like 'superset_saved_query_get_by_id' (read) and 'superset_sqllab_get_saved_queries' (list), but doesn't explicitly contrast them. The purpose is specific but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description mentions saving SQL queries for later reuse, but doesn't specify prerequisites (e.g., authentication), when to use this over other query tools, or any constraints. Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool makes an API request to a specific endpoint and returns 'complete dashboard information including components and layout,' which provides useful context about what data to expect. However, it doesn't mention authentication requirements, error conditions, rate limits, or whether this is a read-only operation (though 'Get' implies it). The description adds some behavioral context but leaves significant gaps for a tool with zero 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement first, followed by implementation details and parameter/return explanations. Every sentence adds value: the first states what it does, the second provides endpoint context, and the last two explain inputs and outputs. There's no redundant information or unnecessary elaboration, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter read operation) with no annotations and no output schema, the description provides a basic but incomplete picture. It covers the purpose, parameter meaning, and return format at a high level, but lacks details about authentication, error handling, or what specific fields the 'complete dashboard information' includes. For a tool with zero structured metadata, the description is adequate but has clear gaps that could hinder effective use.
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 adds meaningful context for the single parameter 'dashboard_id' by explaining it's 'ID of the dashboard to retrieve,' which clarifies its purpose beyond what the schema provides (which has 0% description coverage and only shows it's an integer). Since there's only one parameter and the description explains its role, this compensates well for the schema's lack of documentation. The description doesn't provide format details or constraints, but for a single parameter tool, this is sufficient.
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 with a specific verb ('Get details') and resource ('for a specific dashboard'), making it immediately understandable. It distinguishes this tool from its sibling 'superset_dashboard_list' by focusing on retrieving a single dashboard rather than listing multiple. However, it doesn't explicitly differentiate from other 'get_by_id' tools like 'superset_chart_get_by_id' or 'superset_dataset_get_by_id' beyond the resource 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?
The description implies usage context through the parameter explanation ('ID of the dashboard to retrieve'), suggesting this tool is for when you have a specific dashboard ID. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'superset_dashboard_list' or what prerequisites might be needed (e.g., authentication). The context is clear but lacks explicit when/when-not statements or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the HTTP endpoint ('/api/v1/database/{id}') and return type ('dictionary with complete database configuration information'), which adds useful behavioral context. However, it doesn't mention authentication requirements, error handling, or rate limits, leaving gaps for a read 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 appropriately sized and front-loaded: the first sentence states the purpose, followed by implementation details and parameter/return documentation. Every sentence adds value without redundancy, making it efficient and well-structured.
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 no annotations and no output schema, the description provides adequate basics (purpose, endpoint, parameter meaning, return type) for a simple read tool. However, it lacks details on authentication, error responses, or data format examples, which would enhance completeness for integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description compensates well by explaining the single parameter 'database_id' as 'ID of the database to retrieve.' This adds clear meaning beyond the schema's basic type information. Since there's only one parameter, this is sufficient for effective use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details for a specific database' and 'retrieve detailed information about a specific database connection.' This specifies the verb ('get details/retrieve') and resource ('specific database'), but doesn't explicitly differentiate it from sibling tools like 'superset_database_list' or 'superset_database_get_connection' beyond the 'by_id' aspect.
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 through the parameter description ('ID of the database to retrieve'), suggesting this tool is for fetching details of a known database ID. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'superset_database_list' for browsing or 'superset_database_get_connection' for connection-specific info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it specifies the API endpoint ('/api/v1/chart/{id} DELETE'), warns that the operation is 'permanent and cannot be undone', and describes the return value. This covers key aspects like destructiveness and response format, though it lacks details on permissions 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.
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, followed by endpoint details, warnings, and parameter/return explanations. Every sentence adds value without redundancy, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description does a good job: it explains the action, endpoint, permanence, parameter, and return value. It could be more complete by addressing authentication needs or error cases, but given the tool's simplicity (1 parameter), it's largely 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?
Schema description coverage is 0%, so the description must compensate. It clearly explains the single parameter 'chart_id' as 'ID of the chart to delete', adding essential meaning beyond the schema's basic type (integer). However, it doesn't specify format constraints (e.g., where to obtain the ID) or validation rules, leaving minor gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a chart') and specifies the resource ('a chart'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'superset_dashboard_delete' or 'superset_tag_delete' beyond the chart focus, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It doesn't mention prerequisites (e.g., needing chart_id from 'superset_chart_get_by_id' or 'superset_chart_list'), nor does it contrast with other deletion tools like 'superset_dashboard_delete'. Usage context is implied but not 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 provided, the description carries the full burden of behavioral disclosure. It effectively adds context beyond basic functionality: it specifies the API endpoint ('/api/v1/tag/{id} DELETE'), warns that the operation is 'permanent and cannot be undone' (critical for a destructive action), and hints at the return format ('A dictionary with deletion confirmation message'). This covers key behavioral traits like destructiveness and response structure, though it lacks details on permissions, error handling, or rate limits.
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 appropriately sized and front-loaded: it starts with the core action ('Delete a tag'), followed by implementation details and warnings, then structured Args and Returns sections. Every sentence earns its place by adding value—no redundancy or fluff. The bullet-point style in Args and Returns enhances readability without wasting space.
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 (a destructive delete operation with 1 parameter), no annotations, and no output schema, the description is largely complete. It covers purpose, behavioral warnings, parameter meaning, and return format. However, it misses contextual elements like authentication requirements or error scenarios, which could be important for a mutation tool in this API context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaningful semantics by explaining 'tag_id: ID of the tag to delete', which clarifies the parameter's purpose beyond the schema's basic 'Tag Id' title and integer type. This is sufficient for the single parameter, but it doesn't provide format examples or validation rules, keeping it from a perfect score.
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 verb ('Delete') and resource ('a tag'), making the purpose immediately understandable. It distinguishes itself from siblings like 'superset_tag_create', 'superset_tag_get_by_id', and 'superset_tag_list' by focusing on deletion rather than creation, retrieval, or listing. However, it doesn't explicitly differentiate from 'superset_tag_object_remove', which also removes tags but from objects, so it's not fully specific about sibling differentiation.
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. It doesn't mention prerequisites (e.g., needing tag_id from a list operation), exclusions, or comparisons to sibling tools like 'superset_tag_object_remove' for removing tags from objects. The agent is left without context for tool selection, relying solely on the name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool makes an API request to '/api/v1/me/' and returns a dictionary with user data, which is helpful. However, it doesn't mention behavioral traits like whether it's read-only (implied by 'Get'), potential error conditions, rate limits, or authentication requirements beyond 'authenticated user.' For a tool with zero annotation coverage, this is a moderate but incomplete 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 well-structured and concise: it starts with the core purpose, adds implementation detail about the API endpoint, and ends with return value information. Every sentence adds value without redundancy, and it's appropriately sized for a simple tool with no parameters.
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 (0 parameters, no output schema, no annotations), the description is mostly complete. It explains what the tool does, how it works (API endpoint), and what it returns. However, it could be more complete by explicitly stating it's a read-only operation and clarifying authentication context, which would help the agent use it correctly in workflows.
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 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate. It correctly doesn't discuss parameters, focusing instead on the tool's purpose and behavior.
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: 'Get information about the currently authenticated user' with specific details about retrieving profile information including permissions and preferences. It distinguishes itself from sibling tools like 'superset_user_get_roles' by focusing on the current user's own data rather than role management. However, it doesn't explicitly contrast with other user-related tools (none listed in siblings), so it's not a perfect 5.
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 through 'currently authenticated user,' suggesting it should be used when the agent needs to identify the logged-in user's profile. However, it lacks explicit guidance on when to use this versus alternatives like checking token validity or other auth tools, and doesn't mention prerequisites (e.g., requires prior authentication). This leaves some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context beyond the input schema. It discloses that results are paginated (important for handling large datasets) and that it makes a request to a specific API endpoint (/api/v1/database/). It also mentions access control ('current user has access to'). However, it doesn't specify rate limits, error conditions, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that each add value: stating the purpose, explaining the API call and pagination, and describing the return format. It's front-loaded with the core purpose. While efficient, the third sentence about returns could be slightly more detailed given the lack of output schema.
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 zero-parameter read operation with no annotations and no output schema, the description provides good coverage: purpose, API endpoint, pagination behavior, access context, and return format overview. It adequately compensates for the missing structured fields. However, it could benefit from more detail about the return structure or example output.
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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description appropriately doesn't discuss parameters, maintaining focus on the tool's behavior and output. This meets the baseline of 4 for zero-parameter tools, as no additional parameter information is needed.
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: 'Get a list of databases from Superset' with the specific verb 'Get' and resource 'databases'. It distinguishes from siblings like 'superset_database_get_by_id' by indicating it retrieves multiple items rather than a single one. However, it doesn't explicitly contrast with other list tools like 'superset_database_schemas' or 'superset_database_get_tables'.
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 it retrieves 'all database connections the current user has access to', suggesting it should be used when needing a comprehensive list. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'superset_database_get_by_id' for specific databases or other list tools for different resources. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses this is a POST endpoint call (implying a write operation) and mentions the return format. However, it doesn't cover important behavioral aspects like required permissions, error conditions, rate limits, or whether this operation is idempotent.
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 well-structured with a clear purpose statement, implementation detail, parameter explanations, and return value description. It's appropriately sized for a 4-parameter creation tool, though the API endpoint detail could be considered slightly verbose.
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 creation tool with no annotations and no output schema, the description provides adequate basics but lacks important context. It explains parameters and return format but doesn't cover authentication requirements, error handling, or how this tool relates to the broader Superset dataset management workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides meaningful context for all 4 parameters. It explains what each parameter represents (table name, database ID, schema name, user IDs for ownership) and indicates which are optional vs required, adding significant value 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 specific action ('Create a new dataset'), the resource ('in Superset'), and the source ('from an existing database table or view'). It distinguishes this tool from sibling dataset tools like superset_dataset_get_by_id and superset_dataset_list by focusing on creation rather than retrieval.
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 needing to create a dataset from an existing table/view, but doesn't explicitly state when to use this vs alternatives like superset_chart_create or prerequisites. No explicit exclusions or comparisons to other dataset-related tools 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 provided, the description carries the full burden and adds valuable behavioral context: it specifies the API endpoint ('/api/v1/chart/'), access control ('current user has access to view'), and pagination behavior. It also implies a read-only operation (consistent with 'Get'), though it doesn't detail error handling or rate limits. This compensates well for the lack of annotations.
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 in four sentences: purpose, endpoint/access details, pagination note, and return value summary. Each sentence adds essential information without redundancy, making it front-loaded and easy to parse. There's no wasted text.
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 0 parameters, no annotations, and no output schema, the description provides good completeness: it covers purpose, endpoint, access scope, pagination, and return data structure (including key fields like id, slice_name). However, it doesn't specify the exact format of the 'dictionary' (e.g., keys, nested objects) or error cases, leaving minor gaps for a tool with no structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline of 4. It focuses on the tool's behavior and output instead, which is correct for a parameterless tool.
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: 'Get a list of charts from Superset' with the verb 'Get' and resource 'charts'. It distinguishes from siblings like superset_chart_get_by_id (retrieves a single chart) and superset_chart_create/update/delete (mutations). However, it doesn't explicitly contrast with superset_dashboard_list or other list tools, keeping it at 4 rather than 5.
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 'the current user has access to view' and 'Results are paginated,' suggesting when to use it for retrieving accessible, paginated chart lists. However, it lacks explicit guidance on when to choose this over alternatives like superset_dashboard_list or superset_dataset_list, and doesn't specify prerequisites (e.g., authentication).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it makes an API request to a specific endpoint, results are paginated, and it returns a dictionary with specific fields (id, title, url, metadata). This covers the read-only nature, output format, and pagination behavior, though it doesn't mention authentication requirements or rate limits.
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 appropriately sized. It front-loads the core purpose in the first sentence, adds implementation details in the second, and specifies return values in the third. Every sentence adds value without redundancy, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no annotations, no output schema), the description is reasonably complete. It explains what the tool does, how it works (API endpoint), behavioral traits (pagination), and return format. However, it lacks details on authentication context or error handling, which could be relevant for a tool interacting with an external API.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description adds no parameter information, which is appropriate since there are none. Baseline for 0 parameters is 4, as the description doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get a list of dashboards from Superset' with the specific verb 'Get' and resource 'dashboards'. It distinguishes from siblings like superset_dashboard_get_by_id by specifying it retrieves 'all dashboards' rather than a single one. However, it doesn't explicitly differentiate from superset_chart_list or other list tools beyond mentioning dashboards.
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 stating it retrieves 'all dashboards the current user has access to view', suggesting it should be used when needing a comprehensive list. However, it provides no explicit guidance on when to use this versus alternatives like superset_dashboard_get_by_id for single dashboards or superset_chart_list for charts. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it makes an API request to a specific endpoint, retrieves datasets based on user access permissions, and results are paginated. It also mentions the return format (dictionary with id, table_name, database). This covers authentication needs, response structure, and pagination behavior adequately for a read-only list 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 well-structured and concise: first sentence states the purpose, second provides implementation details and access constraints, third notes pagination, and fourth describes the return format. Every sentence adds value without redundancy, and it's front-loaded with the core functionality.
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 (0 parameters, no annotations, no output schema), the description is fairly complete. It explains what the tool does, how it works (API endpoint), access constraints, pagination, and return structure. For a list tool with no complex inputs or outputs, this provides sufficient context, though it could mention error handling or example usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to add parameter semantics. A baseline of 4 is appropriate for zero-parameter tools, as there's no gap to compensate for.
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: 'Get a list of datasets from Superset' (verb+resource). It distinguishes from siblings like superset_dataset_get_by_id (specific dataset) and superset_dataset_create (create vs list), but doesn't explicitly differentiate from other list tools like superset_chart_list or superset_dashboard_list. The purpose is specific and 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 implies usage context by mentioning 'the current user has access to view' and pagination, suggesting it's for browsing accessible datasets. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., superset_database_get_tables for underlying tables or superset_dataset_get_by_id for a specific dataset). Guidelines are implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it 'Makes a request to the /api/v1/query/ endpoint', results are 'paginated', and includes 'both finished and running queries'. This covers the operation type, endpoint, and result characteristics, though it doesn't mention authentication needs or rate limits.
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 concise: it starts with the core purpose, explains the request and pagination, and ends with return details. Every sentence adds value without redundancy, and it's front-loaded with the main action.
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 low complexity (0 parameters, no output schema, no annotations), the description is reasonably complete. It explains what the tool does, how it behaves (paginated, includes all query states), and what it returns. However, it could be more complete by mentioning authentication requirements or error handling.
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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, and it appropriately focuses on behavior and output. A baseline of 4 is applied for zero 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?
The description clearly states the tool's purpose: 'Get a list of queries from Superset' with the specific verb 'Get' and resource 'queries'. It distinguishes from siblings like 'superset_query_get_by_id' (single query) and 'superset_sqllab_get_saved_queries' (saved vs. history), but doesn't explicitly mention these distinctions in the text.
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 it retrieves 'query history' including 'both finished and running queries', which suggests when to use it (for historical tracking). However, it doesn't provide explicit guidance on when to choose this over alternatives like 'superset_sqllab_get_saved_queries' or 'superset_activity_get_recent'.
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 full burden. It discloses that this is a read-only estimation operation (not execution) and mentions it makes an API request, but doesn't provide details about rate limits, authentication requirements, error conditions, or what specific cost metrics are returned. It adds some behavioral context but leaves significant 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 efficiently structured with a clear purpose statement first, followed by implementation details, then parameter and return value sections. Every sentence adds value with zero wasted words. The four-sentence structure is front-loaded and appropriately sized for this tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema description coverage, the description does an adequate but incomplete job. It covers the basic purpose and parameters but lacks details about authentication, error handling, rate limits, and the structure of the returned cost metrics. For a tool that estimates query costs, more context about what 'cost' means in this system would be helpful.
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?
With 0% schema description coverage, the description must compensate but only partially succeeds. It lists the three parameters with brief explanations, but doesn't provide format details, constraints, or examples. The 'schema' parameter is noted as optional, which helps, but overall the parameter documentation is minimal given the schema provides no 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 clearly states the tool's purpose with specific verb ('Estimate') and resource ('cost of executing a SQL query'), and distinguishes it from siblings like 'superset_sqllab_execute_query' by focusing on estimation rather than execution. The first sentence directly answers 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 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 ('to get approximate cost information for a query before executing it'), which implicitly suggests it should be used prior to execution. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among siblings, though the context implies 'superset_sqllab_execute_query' is the logical follow-up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool makes an API request and retrieves counts and references, which is helpful behavioral context. However, it doesn't mention whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions, leaving gaps in behavioral understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized with four sentences: purpose statement, implementation detail, parameter explanation, and return value description. Each sentence adds value without redundancy, and the information is front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, read-focused operation), no annotations, and no output schema, the description does a reasonably complete job. It explains what the tool does, the parameter meaning, and the return structure. However, it could be more complete by mentioning authentication needs or error handling, which are important for API tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It clearly explains that 'database_id' is the 'ID of the database', adding essential meaning beyond the schema's basic type information. Since there's only one parameter, this provides adequate semantic context, though it doesn't specify format constraints or examples.
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 specific verbs ('Get charts and dashboards') and resources ('associated with a database'), and distinguishes it from siblings like superset_database_get_by_id or superset_database_list by focusing on related objects rather than database properties. The first sentence directly answers 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to find dependencies of a database, but doesn't explicitly state when to use this tool versus alternatives like superset_database_get_by_id for database details or superset_chart_list for all charts. No explicit exclusions or prerequisites are mentioned, leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the action (makes a request to refresh endpoint) and the outcome (returns new token or error). However, it lacks details on authentication requirements, rate limits, error conditions, or whether this invalidates the previous token. For a security-related tool with zero annotation coverage, this leaves significant 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 perfectly structured and concise. The first sentence states the core purpose, the second explains the mechanism, and the third describes the return value. Every sentence adds essential information with zero wasted words, making it easy to parse quickly.
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 this is an authentication tool with security implications, no annotations, and no output schema, the description should provide more complete context. While it covers the basic purpose and mechanism, it lacks information about prerequisites (e.g., must have a valid refresh token), error handling, or what the returned dictionary contains. For this complexity level, the description is adequate but incomplete.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist. It earns a 4 rather than 5 because it could have explicitly stated 'no parameters required' to be perfectly clear, but this is a minor omission.
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 specific verbs ('refresh', 'makes a request') and identifies the exact resource ('access token', '/api/v1/security/refresh endpoint'). It distinguishes this from sibling tools like 'superset_auth_authenticate_user' by emphasizing it works 'without requiring re-authentication with username/password', making the differentiation 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 provides clear context for when to use this tool: when needing a new access token without re-authentication. It implicitly contrasts with 'superset_auth_authenticate_user' by mentioning the alternative approach. However, it doesn't explicitly state when NOT to use it or list all possible alternatives, keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a read operation (retrieving results) and mentions the API endpoint, but lacks details on authentication requirements, rate limits, error handling, or whether the results are cached/paginated. It adds some behavioral context but leaves gaps for a tool that fetches query results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by API details and parameter/return explanations. Every sentence adds value without redundancy, 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.
Completeness3/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 (fetching query results), lack of annotations, and no output schema, the description is adequate but incomplete. It covers the purpose, usage context, and parameter semantics, but misses details on authentication, error cases, and the exact structure of the returned dictionary (though it hints at columns and rows).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It clearly explains that the 'key' parameter is a 'Result key to retrieve' for an asynchronous query, adding essential meaning beyond the schema's basic string type. However, it doesn't specify the format or source of the key (e.g., from 'superset_sqllab_execute_query'), 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 specific action ('Get results'), resource ('previously executed SQL query'), and mechanism ('using its result key'). It distinguishes itself from sibling tools like 'superset_sqllab_execute_query' (which executes queries) and 'superset_sqllab_export_query_results' (which exports results), making the purpose unambiguous.
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: after an asynchronous query has been executed and you have a result key. However, it doesn't explicitly mention when NOT to use it or name specific alternatives (e.g., 'superset_sqllab_execute_query' for initial execution), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively communicates critical behavioral traits: the operation is permanent and cannot be undone, and it makes a DELETE request to a specific API endpoint. This covers the destructive nature and API interaction, though it doesn't mention authentication requirements, rate limits, or error conditions.
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 perfectly structured and front-loaded: the first sentence states the core purpose, followed by implementation details and behavioral warning, then parameter and return documentation. Every sentence adds value with zero wasted words, making it highly efficient and easy to parse.
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 destructive operation with no annotations and no output schema, the description does well: it explains the permanent nature, documents the single parameter, and describes the return value. However, it doesn't cover potential errors, authentication needs, or confirmation prompts, leaving some gaps in completeness for such a high-stakes operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the single parameter, the description must compensate. It clearly explains that 'dashboard_id' is the 'ID of the dashboard to delete', adding essential meaning beyond the schema's basic type information. This adequately documents the parameter's purpose, though it doesn't specify format constraints or provide examples.
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 specific action ('Delete a dashboard') and identifies the resource ('dashboard'), making the purpose immediately evident. It distinguishes this tool from sibling tools like superset_dashboard_create, superset_dashboard_get_by_id, superset_dashboard_list, and superset_dashboard_update by specifying the destructive delete operation.
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 (to permanently remove a dashboard) and implicitly distinguishes it from alternatives like dashboard update or get operations. However, it doesn't explicitly state when NOT to use it or name specific alternative tools, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the operation is permanent and irreversible, it removes associated datasets, and it makes a specific API DELETE request. This covers destructive impact and scope beyond just the database connection itself.
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 perfectly front-loaded with the core purpose in the first sentence, followed by implementation details, behavioral warnings, and parameter/return documentation. Every sentence earns its place with no wasted words, and the structure flows logically from purpose to usage details.
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 destructive tool with no annotations and no output schema, the description provides good completeness: it explains the permanent nature, cascading effects on datasets, API endpoint details, parameter meaning, and return format. The main gap is lack of explicit prerequisites or permission requirements, which would be helpful for a deletion 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?
With 0% schema description coverage and only one parameter, the description adds essential meaning by explaining that 'database_id' is the 'ID of the database to delete'. This fully compensates for the lack of schema documentation, providing clear parameter semantics despite the simple parameter structure.
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 specific action ('Delete a database connection') and resource ('database connection'), distinguishing it from sibling tools like superset_database_create, superset_database_update, and superset_database_list. It uses precise terminology that matches the tool's name and function.
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 by stating it's for deleting database connections, but it doesn't explicitly mention when not to use it or name specific alternatives. It implies usage through the permanent nature of the operation, though lacks explicit exclusions or comparisons to sibling tools like superset_database_update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates that this is a read-only configuration tool ('only returns configuration information'), explicitly states it doesn't require authentication, and describes the return format ('A dictionary with the Superset base URL'). This covers key behavioral aspects for a simple read 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 perfectly structured and front-loaded: the first sentence states the core purpose, followed by usage context, authentication information, and return format. Every sentence earns its place with no redundancy or wasted words. The length is appropriate for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter configuration retrieval tool with no annotations and no output schema, the description provides complete context: purpose, usage scenarios, authentication requirements, and return format. Given the tool's simplicity, no additional information is needed for an agent to understand and use 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?
The tool has 0 parameters with 100% schema description coverage, so the baseline would be 3. However, the description adds value by explicitly stating 'This tool does not require authentication' and clarifying the return format, which provides useful context beyond the empty parameter schema. This justifies a score above baseline.
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 specific action ('Get the base URL') and resource ('of the Superset instance'), distinguishing it from all sibling tools which perform operations on charts, dashboards, databases, etc. It explicitly defines what the tool returns, making its purpose unambiguous.
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 ('for constructing full URLs to Superset resources or for displaying information about the connected instance'), but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools. The guidance is helpful but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it's a write operation (POST request), requires sensitive credentials, has automatic engine determination logic, includes URI format requirements, and mentions validation before creation. The only gap is lack of explicit mention of authentication requirements or rate limits, but it covers most critical behavioral aspects for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with purpose and critical warnings, but contains some redundancy (e.g., repeating 'explicit user consent' concepts) and includes implementation details like the specific API endpoint path that don't help tool selection. The Args/Returns sections are helpful but could be integrated more seamlessly. Some sentences could be more efficiently phrased.
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 creation tool with 4 required parameters, 0% schema coverage, no annotations, and no output schema, the description provides substantial context: purpose, prerequisites, behavioral details, parameter semantics, and return value information. It covers authentication implications through credential requirements and includes error handling context (validation before creation). The main gap is lack of explicit error response information.
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?
With 0% schema description coverage, the description fully compensates by providing rich semantic context for all 4 parameters. It explains engine auto-determination from URI prefixes, typical values for configuration_method, the purpose of database_name, and detailed format requirements for sqlalchemy_uri including examples. The description adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Create a new database connection in Superset' with a specific verb ('create') and resource ('database connection'), distinguishing it from sibling tools like superset_database_list, superset_database_update, and superset_database_delete. It explicitly differentiates this creation function from other database-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with 'IMPORTANT: Don't call this tool, unless user have given connection details' and specifies prerequisites ('explicit user consent and input', 'All connection parameters... must be explicitly provided by the user'). It clearly states when NOT to use the tool (without user confirmation) and what conditions must be met before invocation.
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 the tool makes a request to '/api/v1/me/' to test token validity, which adds useful operational context. However, it lacks details on error handling, rate limits, or performance implications, leaving some behavioral aspects unspecified.
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 concise, with three sentences that each serve a clear purpose: stating the tool's function, explaining the underlying mechanism, and providing usage guidance. There is no wasted text, and information is front-loaded effectively.
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 low complexity (0 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and behavioral aspects adequately. However, it could be slightly enhanced by mentioning the return format more explicitly (e.g., structure of the dictionary) or potential error scenarios, though this is a minor gap.
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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately does not discuss parameters, making it efficient. A baseline of 4 is applied since no parameters exist, and the description avoids unnecessary details.
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 ('Check') and resource ('current access token'), and it distinguishes itself from siblings like 'superset_auth_authenticate_user' or 'superset_auth_refresh_token' by focusing on validation rather than creation or renewal. The phrase 'Check if the current access token is still valid' is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use this to verify authentication status before making other API calls.' This clearly indicates its role as a pre-flight check and distinguishes it from authentication or refresh tools, offering practical context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the multi-step authentication logic (check existing token, refresh if invalid, fall back to re-authentication), the endpoint used (/api/v1/security/login), and the fallback to environment variables. However, it doesn't mention rate limits, authentication requirements for calling this tool, or error handling specifics beyond 'error information'.
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 clear purpose statement first, followed by implementation details, then organized parameter explanations, and finally return value information. Every sentence earns its place by providing essential information without redundancy. The Args/Returns formatting enhances readability.
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 an authentication tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description does an excellent job covering purpose, usage, parameters, and basic return format. However, it could provide more detail about the return dictionary structure and specific error conditions. Given the complexity of authentication flows, slightly more behavioral detail would make it 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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains that username and password fall back to environment variables if not provided, and clarifies that the refresh parameter controls whether to attempt token refresh before re-authentication with a default value of True. This adds significant 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 specific action ('authenticate with Superset and get access token'), identifies the resource (Superset authentication system), and distinguishes from siblings like 'superset_auth_check_token_validity' and 'superset_auth_refresh_token' by describing a comprehensive authentication flow. The first sentence directly answers 'what this tool does' with verb+resource specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: for initial authentication and token management. It distinguishes from sibling tools by explaining this handles the full authentication flow (check existing token, refresh if needed, re-authenticate) rather than just checking validity or refreshing. The context of falling back to environment variables provides additional usage context.
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:

[![superset-mcp MCP server](https://glama.ai/mcp/servers/aptro/superset-mcp/badges/card.svg)](https://glama.ai/mcp/servers/aptro/superset-mcp)

Score Badge

Copy to your README.md:

[![superset-mcp MCP server](https://glama.ai/mcp/servers/aptro/superset-mcp/badges/score.svg)](https://glama.ai/mcp/servers/aptro/superset-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aptro/superset-mcp'

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