Lightdash MCP Server
Server Quality Checklist
Latest release: v0.1.1
- Disambiguation4/5
Most tools have clearly distinct purposes, such as create/list/get/update/delete for charts, dashboards, and spaces. However, there is potential confusion between run-chart-query and run-raw-query, and between get-dashboard-code, get-dashboard-tiles, and get-dashboard-tile-chart-config, though descriptions mitigate ambiguity.
Naming Consistency5/5All tool names follow a consistent verb-noun pattern with hyphens (e.g., create-chart, list-dashboards, get-explore-schema). No mixing of conventions like camelCase or snake_case, making the pattern predictable.
Tool Count4/528 tools is on the higher side but well-justified for a BI server covering charts, dashboards, spaces, explores, queries, and projects. The count reflects comprehensive coverage without being bloated; each tool earns its place.
Completeness4/5The tool set covers CRUD operations for charts, dashboards, spaces, explores, and queries, supporting a full lifecycle. Minor gaps include no general dashboard rename tool (though duplicate-dashboard helps) and no bulk operations, but core workflows are well-supported.
Average 4.4/5 across 28 of 28 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. The verb 'Get' implies a read-only operation, and the description lists the type of information returned, making the behavior clear. However, it does not mention any potential side effects, response format, or error conditions, which would be beneficial for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main statement, bullet points for returned details, a separate usage section, and a parameter section. It is concise and front-loaded, with no unnecessary sentences. Minor improvement could be to integrate the parameter description more naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description provides a high-level overview of what is returned (configuration, warehouse connection, dbt details, metadata). However, it lacks specifics on the exact fields or structure, which might leave an agent needing more detail to decide if the tool meets its needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a detailed description of the project_uuid parameter (mentioning env var and fallback). The tool description's parameter info says 'Optional. If not provided, uses the current/default project,' which is less precise and does not add meaning beyond the schema. It actually omits details, so it provides no added value and may be slightly misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves detailed information about a specific project, using the verb 'Get' and the resource 'project'. It distinguishes itself from sibling tools like list-projects by emphasizing 'detailed configuration information' and listing specific details such as warehouse connection and dbt settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'When to use' section that clearly explains the scenario: when you need detailed configuration information about a specific project. It provides explicit examples of the kind of details returned. However, it does not explicitly state when not to use it or directly name alternative tools like list-projects.
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 does not explicitly state that this tool is read-only or safe to call repeatedly, nor does it mention any authentication or rate-limit considerations. The functional output is described, but behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear sentence, bullet points for returned fields, and a separate usage guidance paragraph. It is front-loaded and each part serves a purpose, though it could be slightly more terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately covers its purpose, returned information, and usage context (UUID requirement for other calls). It provides enough detail for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%, so the description does not need to explain parameter details. The baseline score of 4 is appropriate since the description adds no parameter information but there is no need for it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all projects in the Lightdash organization and specifies the returned fields (UUID, name, type, database connection details, timestamps). It distinguishes itself from sibling tools, none of which perform a similar project listing 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section explicitly advises starting here to discover projects or find UUIDs, and mentions the LIGHTDASH_PROJECT_UUID environment variable as an alternative for other tools. No explicit when-not or alternatives are needed since no other tool lists projects.
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 provided, so description carries burden. States return categories and that it accepts UUID or name with exact match. Lacks explicit statement that it is read-only or details on error handling/performance, but adequately describes the operation's scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with bullet points and headings. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no output schema, the description covers key return categories (chart config, metrics, table config, metadata). Could add more detail on response structure, but sufficient for agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter clearly described. Description adds 'will search for exact match' nuance, but schema already explains the parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a specific saved chart' and lists specific return categories, distinguishing it from sibling tools like get-dashboard-tile-chart-config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly listed 'When to use' bullet points (before modifying, understanding config, extracting query logic, debugging). No explicit when-not-to-use or alternative tools mentioned, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses the two behaviors (saved vs dashboard-only) and the full list of returned configurations. It mentions partial matching support. No contradictions or hidden side effects described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (introduction, returns, usage, parameters). Front-loaded with main purpose. Contains one minor typo ('a a chart' in second bullet of usage) but otherwise every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two parameters, no output schema, and the tool's retrieval nature, the description is comprehensive. It explains the difference between chart types and lists all config components. Could mention error handling (e.g., tile not found) but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal new meaning beyond schema: both parameters already have descriptions mentioning partial matching. The context of use is provided but doesn't significantly enhance the schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the complete chart configuration for a dashboard tile, distinguishing between saved charts and dashboard-only charts. It specifies the exact components returned (metricQuery, chartConfig, etc.) and separates from sibling tools like get-dashboard-tiles or get-chart-details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
A 'When to use' section provides four explicit contexts (getting full details, understanding dashboard-only charts, exporting, before modifying). It implicitly differentiates from get-chart-details for saved charts, but could be more explicit about alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It describes the tool as executing queries but does not explicitly state that it is read-only, idempotent, or requires specific permissions. The description includes detailed input rules but omits safety or side-effect information, which is a gap for a query 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings, bullet points, and a complete example. It is informative but slightly lengthy; however, each sentence adds value. Could be trimmed slightly, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly explains input configuration but lacks information about the return format, error handling, or how to interpret results. Since there is no output schema, the description should cover what the tool returns. This gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds significant value beyond the schema, including a complete working example, key rules for field IDs, filter syntax, and additional metrics. This clarifies the complex 'metric_query' parameter effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a raw metric query against a Lightdash explore', specifying the verb (execute) and resource (raw metric query). It distinguishes from siblings like 'run-chart-query' by noting use cases such as ad-hoc analysis, dashboard-only charts, and debugging, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool (ad-hoc analysis, dashboard-only charts, debugging) and references 'get-explore-schema' for field IDs. However, it does not explicitly state when NOT to use it (e.g., prefer 'run-chart-query' for saved charts), though sibling tools provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the optional include_full_config behavior and return fields, but does not mention side-effect-free nature, permissions, or rate limits. Acceptable for a read tool, but could be more explicit about safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with a clear summary, followed by a bulleted return field list, and a 'When to use' section. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description adequately explains return values. It covers all key fields and the optional configuration. Minor missing details like error cases or pagination, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds contextual value by explaining that dashboard_name supports partial case-insensitive matching and that include_full_config provides full chart configuration for each tile, extending beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all tiles from a specific dashboard' and enumerates the return fields, distinguishing this read operation from sibling tools like create-dashboard-tile, update-dashboard-tile, and delete-dashboard-tile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section lists five specific use cases, such as finding a tile's UUID for update/delete, understanding layout, or getting full configuration. It lacks explicit when-not-to-use or alternatives, but the provided guidance is comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It notes potential for large data return, which is a key behavioral trait. Describes it as a catalog listing, implying read-only, but doesn't explicitly confirm no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, bullet points, and clear headings. Every sentence adds value. Front-loaded with purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, when to use, and a behavioral note. Given one optional parameter and no output schema, the description is sufficient. Could mention authentication or error cases, but not necessary for core understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one optional parameter. Description restates the schema description ('Optional: UUID of the project. If not provided, uses current project.') without adding new semantic value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all available explores/tables in the project catalog' and enumerates returned content (names, descriptions, SQL references). It distinguishes from sibling tools like get-explore-schema by indicating that list-explores is for initial discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: for discovery, browsing catalog, before using get-explore-schema. Includes best practice. Does not explicitly state when not to use, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return format (CSV with metadata), real-time execution, performance notes, and optional limit. Does not explicitly state read-only, but implied by 'execute a chart query'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-organized with sections, front-loaded with core purpose. Every sentence provides value, no fluff. Approximately 150 words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and moderate complexity, description covers purpose, usage, return format, and performance. Missing example or error handling, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds marginal value. It reiterates limit's purpose and provides example, but chart_uuid description repeats schema. Baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'executes a chart query and returns data in CSV format.' It uses specific verb+resource, and distinguishes from siblings like run-dashboard-tiles and run-raw-query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section lists four appropriate scenarios (getting data, verifying chart, exporting, previewing). It lacks explicit exclusions or alternatives, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It explains tile types and positioning but lacks details on idempotency, return value, error handling for duplicate names, or required permissions. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, bullet points, and separate usage guidelines. While slightly lengthy, every sentence adds meaningful information. No unnecessary redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet description does not specify return value or confirmation of creation. However, for a creation tool with 4 parameters and clear schema, the description covers creation process and use cases sufficiently. Minor gap on output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds extra value by detailing tile types, properties structure, and positioning, which enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new dashboard, and distinguishes from siblings like duplicate-dashboard and create-dashboard-tile. It specifies the ability to create empty or fully configured dashboards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section lists three scenarios and references alternative tool (duplicate-dashboard). Best practice recommendation to start empty and use create-dashboard-tile provides further guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses that these are user-defined metrics stored separately from dbt models, and that it returns definitions, SQL expressions, associated tables, and labels. It does not mention any side effects or destructive actions, which is appropriate 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs and bullet points, making it easy to scan. It is clear and informative without being overly verbose, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists return fields and clearly explains the tool's function. For a simple get operation with one optional parameter, it provides sufficient context. Possible minor improvements: mention if pagination is supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single optional parameter, so the description adds no new information beyond 'if not provided, uses current project' which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves custom metrics defined in the project, distinguishes them from dbt model metrics, and lists return fields. The verb 'Get' clearly identifies the action, and the resource 'custom metrics' is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'When to use' section with three specific scenarios: discovering custom business metrics, understanding custom calculations, and before using a metric in a chart/query. It also notes the difference from dbt model metrics, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It correctly identifies the operation as renaming by updating the title property. While it lacks details on side effects or permissions, the operation is simple and the description is straightforward. Could be slightly improved by noting immediate effect or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, using only necessary sentences. Front-loaded with the main purpose. Uses section headers for guidelines. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing information about return values or success indicators (no output schema). Does not mention error cases or prerequisites (e.g., tile must exist). But for a simple rename, it covers the essential context of what the tool does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with clear parameter descriptions. The description adds no additional semantic information beyond what the schema provides, but the schema is already sufficient. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rename a tile) and resource (dashboard tile) with specific verb+resource. It distinguishes itself from the sibling 'update-dashboard-tile' by noting it is a convenience tool for a single property update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description includes explicit when-to-use scenarios (markdown tile, chart tile display name, quick updates) and explicitly mentions when not to use (complex updates: use update-dashboard-tile). Provides clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool fetches dashboard configuration once and executes tiles in parallel. It also describes the return format including error handling for failed tiles. This provides sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with clear sections for 'When to use' and 'Returns'. It is front-loaded with the main action. There is no redundant information, and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return values: a dictionary with keys for tile UUIDs, containing title, status, csv_data (with metadata), and error. It covers input parameters and behavior (parallel execution, fetching config once). It is complete for an AI agent to understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds valuable context: explaining that if tile_uuids is omitted or empty, all chart tiles are executed. It also details the return structure (tile UUIDs as keys, status, csv_data, error). This goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs one or multiple dashboard tiles concurrently. It distinguishes from sibling tools like run-chart-query by focusing on dashboard tiles. The verb 'run' and resource 'dashboard tiles' are specific 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'When to use' section that lists appropriate scenarios: downloading entire dashboard data or getting data from multiple specific tiles. It does not explicitly state when not to use, but the context is clear enough for an AI to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the 36-column grid system, ability to modify multiple properties in one operation, and separates position vs display properties. It does not mention permissions or reversibility but adds substantial context beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, bullet points, and examples. Front-loaded with main purpose. Some redundancy (repeats example values) but overall efficient and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return values or effects. It doesn't mention response or confirmation of update. It covers usage and parameters well but lacks output/confirmation info, making it slightly incomplete for an agent expecting feedback.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds critical meaning: explains grid system for positioning, provides multiple examples for properties_update, clarifies structure (position at tile level, display in properties object). This significantly enriches the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates tile properties, lists specific properties (position, display), and distinguishes from sibling tools like rename-dashboard-tile. It uses specific verbs and identifies the resource (tile on dashboard).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section explicitly lists scenarios like repositioning, resizing, updating multiple properties, and swapping charts. It provides clear context but does not explicitly mention when not to use or name alternative tools, though inference is possible.
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?
The description describes return values (metadata fields) and implies a safe read operation. With no annotations, it carries the full burden but is sufficiently transparent for a list tool, though it could mention permission scoping or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear single-sentence purpose, a bullet list of return data, and separate 'When to use' and 'Next steps' sections. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one optional param) and no output schema or nested objects, the description is fairly complete. It covers purpose, return data, and usage context, though it lacks details on ordering or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage on the single optional parameter project_uuid. The description does not add extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all dashboards' with a specific resource and action, and the 'When to use' section distinguishes it from sibling tools like list-charts and list-spaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section provides three clear scenarios for using the tool, and 'Next steps' suggests specific follow-up tools (get-dashboard-tiles, get-dashboard-code), giving clear guidance on alternatives.
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 bears full burden for behavioral disclosure. It accurately describes the search behavior (case-insensitive partial matching) and specifies return fields (UUID, name, space, description). It does not mention potential limits like pagination or result count, but for a search tool of this simplicity, the transparency is largely sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: a clear first sentence, bullet points for matching fields and return fields, and separate sections for usage guidance and differentiation. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and no output schema, the description adequately covers input, behavior, and output fields. It does not mention ordering or pagination, but this is acceptable for most use cases. The context from sibling tools supports completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a detailed description of the 'search_term' parameter with an example. The tool description reinforces the case-insensitive and partial matching behavior but does not add substantial new meaning beyond the schema. With 100% schema coverage, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for charts by name or description with case-insensitive partial matching. It explicitly distinguishes from the sibling tool 'list-charts' by noting that this tool searches both name and description, while the other only filters by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'When to use' section with three specific scenarios and a 'Difference from list-charts' section, providing clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses behavioral traits: it uses a PATCH endpoint, merges updates, and lists updatable fields. It also warns about JSON string parameters. It lacks details on error handling, rate limits, or permanence, but overall provides sufficient transparency for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (purpose, updatable fields, common use cases, important notes, example) and uses markdown for readability. It is slightly verbose due to multiple examples, but every part earns its place for clarity. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, partial updates, JSON inputs) and the absence of an output schema, the description covers usage patterns, merge behavior, and prerequisite steps. It is missing a description of the return value, but overall provides a complete understanding for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so baseline is 3. The description significantly adds value by providing concrete examples for each parameter (e.g., changing sorts, filters, chart type) and explaining how to use JSON strings. This exceeds the baseline and helps the agent understand parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing saved chart's configuration' using a specific verb and resource. It distinguishes from sibling tools like create-chart and delete-chart by specifying partial updates and listing common use cases that differentiate it from querying or read operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool allows partial updates and provides common use cases and important notes, including recommending 'Use get-chart-details first to see current configuration.' However, it does not explicitly contrast with when to use alternative tools like run-chart-query for testing queries, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: details the grid system (36 columns), tile-specific required fields, and positioning. It does not mention side effects like overwriting, but creation is inherently non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and examples, but slightly verbose. Every sentence adds value, and critical information (grid system) is highlighted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of multiple tile types and no output schema, the description thoroughly explains all necessary details for correct invocation, including parameter usage and best practices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the schema, detailing tile-specific properties for each type (saved_chart, markdown, loom) and the grid system. Schema coverage is 100%, but the description provides execution-critical examples and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new tile and adds it to an existing dashboard, with explicit tile types and their requirements. It distinguishes from siblings like 'create-chart' and 'delete-dashboard-tile' by focusing on tile creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section lists three specific use cases, and the best practice to first retrieve existing tiles provides context. However, it does not explicitly exclude alternatives or compare to siblings like 'update-dashboard-tile'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly states the tool is read-only and lists the information returned (UUID, name, space, description, last updated). No hidden side effects or requirements are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear first sentence, a bullet list of return information, and a dedicated 'When to use' section. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter. Despite no output schema, the description adequately lists the return fields, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds value by providing an explicit usage example for the search_term parameter, enhancing understanding beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The purpose is crystal clear: 'List all saved charts in the Lightdash project.' It specifies the verb (list) and resource (charts) and distinguishes itself from sibling tools like 'search-charts' which likely has different functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' bullet points covering common use cases. However, it does not explicitly state when not to use or compare to similar tools like 'search-charts', though the usage guidance is still helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully explains the read-only behavior and the returned fields (UUID, name, private flag, counts) and space types. Omits pagination or limits, but acceptable for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main purpose, uses bullet points and clear sections, no wasted words. Every sentence adds value, and structure aids quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description fully covers purpose, usage, return values, and space types. Sufficient for an AI agent to decide when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% (vacuously). Description adds value by explaining the tool's behavior and return values beyond the empty schema, meeting the baseline of 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all spaces (folders) in the Lightdash project' with a specific verb and resource, and distinguishes itself from sibling tools like create-space and delete-space by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' bullet points (e.g., discover structure, find UUIDs) and describes space types, giving clear context for usage. Lacks explicit alternatives or when-not-to-use, but is well-implied by sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that changes apply immediately to all dashboard viewers, which is a critical behavioral trait. No annotations provided, so description carries this burden. It also recommends verification via run-dashboard-chart, implying no built-in validation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, user benefits, filter structure, usage scenarios, important note, testing tip). Every sentence is informative and earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description fully explains the input format and behavior. It covers the filter structure in detail and provides usage guidance, making it complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by explaining the filter configuration structure, listing supported operators and time-based filters, and providing an example JSON.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'dashboard-level filters', and distinguishes from sibling tools like update-chart and update-dashboard-tile by focusing on filters that apply to all tiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section lists specific scenarios (e.g., adding global date range selectors, creating region/category filters). It also suggests testing after update. It does not explicitly exclude chart-specific filter updates, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It details that the chart is saved in a space, requires precise configuration, and warns that a wrong structure will break the chart. It also mentions server-side validation and auto-generation, providing a complete behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long with multiple sections and verbose examples. While well-organized for complexity, it sacrifices conciseness. Every sentence is informative, but the overall length could be reduced without losing essential guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 5 required, no output schema), the description is thoroughly complete. It covers metric queries, chart configs, pivot configs, custom dimensions, chart types, and validation—addressing all potential user needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already has 100% coverage, the description adds immense value with complete working examples, naming conventions, filter structures, custom dimension patterns, and validation rules. This goes far beyond the schema's basic parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new saved chart in a space' and lists required components (table name, metric query, chart configuration). It distinguishes the tool from siblings like update-chart and delete-chart by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive examples and key rules, implicitly guiding when to use this tool (creating a chart). It lacks explicit comparison to alternatives like run-chart-query but covers use cases and critical warnings, which is sufficient for a creation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the destructive nature ('permanently removes', 'cannot be undone'), effects on saved charts versus dashboard-only charts, and automatic saving after deletion. This provides comprehensive behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings, bullet points, and concise sentences. Each section serves a distinct purpose: purpose, usage, important notes, and search behavior. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all critical aspects for a deletion tool: irreversibility, effect on charts, automatic saving, and search behavior. However, it does not address error scenarios (e.g., tile not found) or specify the output of the operation. Given no output schema, slightly more detail on expected results could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage). The description adds value by explaining partial matching behavior for dashboard_name and tile_identifier, including an example for tile_identifier. This enriches the schema information without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: permanently deleting a tile from a dashboard. It uses specific verbs ('Delete') and resource ('tile'), and distinguishes it from sibling tools like rename-dashboard-tile or update-dashboard-tile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (removing outdated tiles, cleanup, replacing tiles) and implies when not to use (e.g., when the chart itself should be preserved). However, it lacks explicit alternative tool names for related operations, such as delete-chart for deleting the underlying chart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses constraints (cannot delete if contains charts/dashboards, permanent operation), input types (UUID or name), and prerequisite steps. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and bullet points. Every sentence adds value, though slightly verbose. Could be more concise but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 1 parameter, no output schema, and no annotations, the description covers constraints, usage, steps, and input details comprehensively. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single parameter, and the description adds only minor clarification about exact match for name. Baseline is 3 due to high schema coverage; description adds marginal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a space (folder)' with a specific verb and resource. It distinguishes from sibling tools like create-space and list-spaces by focusing on the deletion action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (remove empty/unused spaces, clean up, after moving content) and provides steps to delete a space with content. Offers clear guidance on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses creation behavior, notes the response contains the space UUID, and mentions private vs public spaces. However, it does not specify error conditions like duplicate names or permission requirements, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, bullet points for use cases and best practices, and no redundant information. Every sentence adds value, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (2 params) and no output schema, the description covers purpose, usage context, parameter guidance, and what to expect from the response (space UUID). It is complete for an agent to correctly select and use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters ('name', 'is_private') have descriptions in the schema. The description adds context with examples of space categories and best practices for naming and privacy, enhancing understanding beyond the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a 'space (folder)' for organizing charts and dashboards. The verb 'create' combined with the resource 'space' is specific. It distinguishes from siblings like 'create-chart' and 'create-dashboard' by focusing on organizational structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'When to use' section with three bullet points covering before creating charts, organizing content, and setting up restricted areas. 'Best practices' offer further guidance. This clearly tells the agent when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly lists what gets copied (tiles, tabs, filters, layout), what gets regenerated (UUIDs), and what stays the same (chart references). This is comprehensive for a duplicate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and bullet points. Every sentence adds value. The core purpose is front-loaded immediately. No wasted words for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the behavior (complete copy, UUID regeneration, chart references preserved). It includes all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining 'partial matching' for source_dashboard_name and uniqueness requirement for new_dashboard_name, which go beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create a complete copy of' and identifies the resource as an 'existing dashboard with a new name'. It clearly distinguishes from 'create-dashboard' by emphasizing copying rather than creation from scratch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section lists four concrete scenarios (e.g., creating variants, test versions). It implicitly suggests when not to use (e.g., when creating from scratch, use create-dashboard). Could be improved by explicitly naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description thoroughly explains the return value (config details) and implies a read-only operation, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and sections, each sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently details the return content (tiles, tabs, filters, layout, chart references) and use cases, making it complete for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description already includes 'supports partial matching'. The tool description adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the complete dashboard configuration with full tile definitions, and distinguishes from the sibling tool 'duplicate-dashboard' by noting it as an alternative for simpler copying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'Use cases' sections, including a specific alternative tool, provide clear guidance on when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses return structure (base table info, dimensions, metrics, joins, summary stats), field details, and hidden fields behavior. It does not mention idempotency or side effects, but for a read-only tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points, and clear formatting. It is detailed but not verbose; every sentence adds value. Information is front-loaded with the core purpose, then detailed sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description provides extensive detail on return content (field IDs, types, labels, SQL, descriptions, joins). For a schema retrieval tool, this covers all necessary aspects and compensates fully for the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters documented). The description adds value beyond schema: for table_name it gives concrete examples and references get-catalog; for include_hidden it clarifies what hidden fields are. This helps the agent use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the complete schema for an explore/table including all available dimensions, metrics, and joins.' It uses a specific verb and resource, and distinguishes from sibling tools like get-catalog (which lists explores) and run-chart-query (which uses the schema).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'When to use' section listing explicit scenarios (e.g., before creating any chart) and 'Best practices' with sequential steps referencing sibling tools like get-catalog. It provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Warns that operation is destructive and irreversible, and that dashboard references will break. Suggests checking dependencies beforehand. No annotations exist, so description carries full burden and handles it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with separate sections for warning, usage, notes, and accepted input. Front-loaded with purpose. Every sentence is informative, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all relevant aspects: destructive nature, dependencies, alternatives, input types, and consequences. No output schema needed for delete; description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description. Description adds clarification that name search is exact match, but largely reinforces schema. Minor added value above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Delete a saved chart from the project' with specific verb and resource. Distinguishes from sibling tools like update-chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios (outdated charts, test cleanup, recreation) and when not (modifications, recommends update-chart). Also advises checking dashboard dependencies.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/poddubnyoleg/lightdash_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server