Supports syncing TikTok Ads campaign data to Lark Base tables for dashboard visualization and reporting.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Hype Dash create a bar chart showing monthly sales from the sales table"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Production-ready TypeScript SDK for creating and managing Lark/Feishu dashboards via REST API with Model Context Protocol (MCP) server support.
Type-Safe: Full TypeScript support with comprehensive type definitions
Fluent API: Intuitive builder pattern for creating dashboard blocks
7 Block Types: Charts, Metrics, Views, Text, Lists, Tab Pages, and Filters
MCP Server: Native Claude Code integration via Model Context Protocol
Production Ready: Error handling, retries, logging, and validation
Batch Operations: Efficiently create multiple blocks at once
2025 Dashboard Features: Latest Lark dashboard capabilities
Python SDK: Comprehensive Python SDK for Lark Base data management
Related MCP server: mcp-boilerplate
npm install @hypelab/hype-dashcd python
pip install -r requirements.txtSee Python SDK Documentation for detailed setup and usage.
import { LarkDashboardClient, ChartBlockBuilder, AggregationType } from '@hypelab/hype-dash';
const client = new LarkDashboardClient({
apiKey: process.env.LARK_API_KEY!,
region: 'sg', // 'sg' | 'cn' | 'us'
logging: true,
});
// Create a dashboard
const dashboardId = await client.createDashboard({
name: 'Sales Dashboard',
appToken: 'YOUR_APP_TOKEN',
});
// Add a bar chart
const chartBlock = ChartBlockBuilder.bar()
.dataSource('YOUR_APP_TOKEN', 'YOUR_TABLE_ID')
.xAxis({ fieldName: 'Category' })
.yAxis([{ fieldName: 'Revenue', aggregation: AggregationType.SUM }])
.title('Revenue by Category')
.colors(['#3b82f6', '#10b981', '#f59e0b'])
.build();
await client.addBlock('YOUR_APP_TOKEN', dashboardId, chartBlock);import { ChartBlockBuilder, ChartType, AggregationType } from '@hypelab/hype-dash';
// Bar Chart
const barChart = ChartBlockBuilder.bar()
.dataSource(appToken, tableId)
.xAxis({ fieldName: 'Month' })
.yAxis([
{ fieldName: 'Sales', aggregation: AggregationType.SUM, label: 'Total Sales' },
{ fieldName: 'Orders', aggregation: AggregationType.COUNT, label: 'Order Count' }
])
.title('Monthly Sales Performance')
.showLegend(true)
.build();
// Line Chart
const lineChart = ChartBlockBuilder.line()
.dataSource(appToken, tableId)
.xAxis({ fieldName: 'Date' })
.yAxis([{ fieldName: 'Revenue', aggregation: AggregationType.SUM }])
.build();
// Pie Chart
const pieChart = ChartBlockBuilder.pie()
.dataSource(appToken, tableId)
.series({ fieldName: 'Category' })
.yAxis([{ fieldName: 'Amount', aggregation: AggregationType.SUM }])
.build();import { MetricsBlockBuilder, AggregationType } from '@hypelab/hype-dash';
const metrics = new MetricsBlockBuilder()
.dataSource(appToken, tableId)
.fieldName('Revenue')
.aggregation(AggregationType.SUM)
.title('Total Revenue')
.prefix('$')
.decimals(2)
.trendComparison(30, 'days')
.build();import { ViewBlockBuilder, ViewType } from '@hypelab/hype-dash';
const tableView = ViewBlockBuilder.table()
.dataSource(appToken, tableId, viewId)
.title('Customer List')
.showToolbar(true)
.height(400)
.build();
const kanbanView = ViewBlockBuilder.kanban()
.dataSource(appToken, tableId, viewId)
.build();import { TextBlockBuilder } from '@hypelab/hype-dash';
const heading = new TextBlockBuilder()
.heading('Dashboard Overview')
.alignment('center')
.build();
const paragraph = new TextBlockBuilder()
.paragraph('Welcome to the sales dashboard.')
.build();The SDK includes a Model Context Protocol server for Claude Code integration.
Add to your ~/.claude.json or Claude Code configuration:
{
"mcpServers": {
"hype-dash": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@hypelab/hype-dash"],
"env": {
"LARK_API_KEY": "your-api-key-here",
"LARK_REGION": "sg"
}
}
}
}create_dashboard - Create a new dashboard
create_chart_block - Add chart visualizations
create_metrics_block - Add KPI metrics
create_view_block - Add table/kanban views
create_text_block - Add text content
list_dashboards - List all dashboards
delete_dashboard - Remove dashboards
Create a sales dashboard with:
- Bar chart showing revenue by month
- KPI card for total revenue
- Table view of recent ordersClaude will use the MCP tools to create the dashboard automatically.
The project includes a comprehensive Python SDK for managing Lark Base data. This allows you to:
Sync External Data: Import data from TikTok Ads, databases, APIs, etc.
Batch Operations: Efficiently create/update thousands of records
Data Transformation: Transform and validate data before loading
Automatic Dashboard Updates: Dashboards automatically reflect data changes
from lark_client import LarkBaseClient, LarkConfig
from data_manager import DataManager
# Initialize client
config = LarkConfig(
app_id=os.getenv('LARK_APP_ID'),
app_secret=os.getenv('LARK_APP_SECRET')
)
client = LarkBaseClient(config)
data_manager = DataManager(client)
# Sync TikTok campaign data
tiktok_data = fetch_tiktok_campaigns() # Your data source
result = data_manager.batch_upsert_records(
app_token='YOUR_APP_TOKEN',
table_id='YOUR_TABLE_ID',
records=tiktok_data,
key_field='campaign_id'
)
print(f"Synced {result['total']} campaigns")
# Your dashboards now show updated data automatically!Full CRUD operations for tables, fields, and records
Batch operations with automatic pagination
Data validation and transformation utilities
Incremental sync with timestamp tracking
Field mapping for external data sources
Rate limiting and error handling
Comprehensive logging
See Python SDK Documentation for complete guide.
Python: Manage data (create tables, sync external sources, batch updates)
TypeScript: Create beautiful dashboards to visualize the data
Automatic: Dashboards update automatically when data changes
# 1. Python: Sync data
data_manager.batch_upsert_records(...)// 2. TypeScript: Create dashboard
const chart = ChartBlockBuilder.bar()
.dataSource(appToken, tableId)
.build();const client = new LarkDashboardClient({
apiKey: string; // Required: Lark API key
region?: 'sg' | 'cn' | 'us'; // Default: 'sg'
apiUrl?: string; // Optional: Custom API URL
logging?: boolean; // Default: false
timeout?: number; // Default: 30000ms
maxRetries?: number; // Default: 3
retryDelay?: number; // Default: 1000ms
});LARK_API_KEY=your-api-key
LARK_REGION=sg
LARK_LOGGING=trueconst blocks = [
ChartBlockBuilder.bar().dataSource(appToken, tableId).build(),
MetricsBlockBuilder.sum('Revenue').dataSource(appToken, tableId).build(),
ViewBlockBuilder.table().dataSource(appToken, tableId, viewId).build(),
];
const results = await client.batchCreateBlocks(appToken, blocks);import { FilterOperator, FilterConjunction } from '@hypelab/hype-dash';
const chart = ChartBlockBuilder.bar()
.dataSource(appToken, tableId)
.filters(FilterConjunction.AND, [
{ fieldName: 'Status', operator: FilterOperator.IS, value: 'Active' },
{ fieldName: 'Revenue', operator: FilterOperator.GT, value: 1000 }
])
.build();import { ValidationError } from '@hypelab/hype-dash';
try {
await client.addBlock(appToken, dashboardId, block);
} catch (error) {
if (error instanceof ValidationError) {
console.error('Validation failed:', error.message);
} else {
console.error('API error:', error);
}
}createDashboard(dashboard: Dashboard): Promise<string>
addBlock(appToken: string, dashboardId: string, block: DashboardBlock): Promise<string>
updateBlock(appToken: string, blockId: string, block: Partial<DashboardBlock>): Promise<void>
deleteBlock(appToken: string, blockId: string): Promise<void>
listBlocks(appToken: string): Promise<DashboardBlock[]>
batchCreateBlocks(appToken: string, blocks: DashboardBlock[]): Promise<BatchOperationResult[]>
ChartBlockBuilder - Create chart visualizations
MetricsBlockBuilder - Create KPI metrics
ViewBlockBuilder - Create data views
TextBlockBuilder - Create text blocks
ListBlockBuilder - Create list blocks (2025)
TabPageBlockBuilder - Create tab pages (2025)
See the /examples directory for complete examples:
basic-dashboard.ts - Simple dashboard creation
complete-dashboard.ts - Full-featured dashboard
multi-source-dashboard.ts - Multiple data sources
realtime-dashboard.ts - Real-time data updates
The SDK is written in TypeScript and provides comprehensive type definitions:
import type {
DashboardBlock,
ChartConfig,
MetricsConfig,
ViewConfig,
ChartType,
ViewType,
AggregationType,
} from '@hypelab/hype-dash';Node.js >= 16.0.0
TypeScript >= 5.0.0 (for TypeScript projects)
Python >= 3.8
See python/requirements.txt for dependencies
Authentication Errors
Verify your LARK_API_KEY is correct
Check API key permissions in Lark admin console
Ensure region matches your Lark workspace ('sg', 'cn', or 'us')
Network Errors
Check firewall settings
Verify network connectivity to Lark API
Try increasing timeout in client config
Validation Errors
Ensure required fields are provided
Check data types match API expectations
Verify field names exist in your Lark tables
Contributions are welcome! Please see CONTRIBUTING.md for guidelines.
MIT License - see LICENSE file for details.
GitHub Issues: https://github.com/hypelab/hype-dash/issues
Email: dev@hypelab.com
See CHANGELOG.md for version history and updates.
Create a chart block (bar, line, pie, scatter, area, column, funnel, radar, table) and add it to a dashboard
| Name | Required | Description | Default |
|---|---|---|---|
| app_token | Yes | Base app token | |
| dashboard_id | Yes | Dashboard block ID | |
| chart_type | Yes | Type of chart | |
| table_id | Yes | Source table ID | |
| view_id | No | Optional view ID to filter data | |
| x_axis_field | Yes | Field name for X axis | |
| y_axis_fields | Yes | Y axis configuration (can have multiple) | |
| title | No | Chart title | |
| show_legend | No | Show legend | |
| colors | No | Custom colors (hex codes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only reveals the tool creates and adds a chart block, but does not disclose mutation behavior, side effects, or constraints (e.g., whether existing blocks are affected, limits, or required permissions). This is insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key action. However, it could be slightly more structured (e.g., separate purpose and parameters). Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 6 required, chart types with y-axis config) and no output schema, the description is too brief. It does not cover return values, error handling, placement details, or scope of the creation. The agent is left with many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema provides (e.g., listing chart types already in enum). No extra context on parameter usage is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (chart block) with specific chart types (bar, line, pie, etc.), and explicitly mentions adding it to a dashboard. This distinguishes it from sibling tools like create_text_block or create_metrics_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., other block creation tools) and lacks any prerequisites or exclusions. The agent must infer from the sibling names, but no explicit usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new dashboard in a Lark Base by copying an existing one. Note: Lark API does not support creating dashboards from scratch - this copies an existing dashboard. If no source_block_id is provided, it will automatically copy the first available dashboard. Returns the new dashboard ID.
| Name | Required | Description | Default |
|---|---|---|---|
| app_token | Yes | Base app token (e.g., "FUVdb7bebaVLeMsKJgJlnsX2gzd") | |
| name | Yes | Dashboard name | |
| source_block_id | No | Optional: Block ID of existing dashboard to copy from (e.g., "blkxYx6MmEeujy0v"). If not provided, copies the first available dashboard. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description fully conveys the key behavioral traits: it copies an existing dashboard, falls back to the first available if no source_block_id is given, and returns the new dashboard ID. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, and every sentence adds value. No redundant or vague phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no output schema, and no annotations, the description covers the tool's behavior, parameters, and return value adequately. It explains a crucial limitation (no scratch creation) which completes the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the description adds meaning by explaining the purpose of source_block_id (optional, fallback), and the necessity of app_token. It goes beyond schema by describing the copy mechanism.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new dashboard in a Lark Base by copying an existing one,' specifying the verb (create), resource (dashboard), and method (copy). It distinguishes from sibling tools like create_chart_block, which create different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (when a new dashboard is needed) and notes the API limitation (cannot create from scratch). It also clarifies behavior if source_block_id is omitted. However, it does not explicitly exclude scenarios or suggest alternatives like using list_dashboards first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a metrics/KPI block showing aggregated values
| Name | Required | Description | Default |
|---|---|---|---|
| app_token | Yes | Base app token | |
| dashboard_id | Yes | Dashboard block ID | |
| table_id | Yes | Source table ID | |
| field_name | Yes | Field to aggregate | |
| aggregation | Yes | Aggregation type | |
| title | No | Metrics title | |
| prefix | No | Prefix (e.g., "$", "€") | |
| suffix | No | Suffix (e.g., "%", "units") | |
| decimals | No | Decimal places |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'create a metrics/KPI block' but fails to mention permissions required, side effects, or any limitations on usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is appropriately sized, though it could be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema or annotations, the description is inadequate. It does not explain how parameters interact, output format, or any constraints, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema; 'showing aggregated values' is already implied by the aggregation parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a metrics/KPI block showing aggregated values' clearly states the action (create) and the resource (metrics/KPI block), and it distinguishes from sibling tools like create_chart_block, create_text_block, and create_view_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without any context on prerequisites, conditions, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a text/markdown block with formatted content
| Name | Required | Description | Default |
|---|---|---|---|
| app_token | Yes | Base app token | |
| dashboard_id | Yes | Dashboard block ID | |
| content | Yes | Text content | |
| is_heading | No | Format as heading | |
| alignment | No | Text alignment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only says 'Create' without disclosing permissions, effects, or whether it appends or replaces blocks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no fluff; could be slightly more informative but remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes the core action but lacks details on return values, tie to dashboard_id, and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions; the description adds no extra meaning beyond 'formatted content'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a text/markdown block, distinguishing it from sibling tools like create_chart_block or create_metrics_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; purpose is implied but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a view block (grid, kanban, gallery, gantt, form) showing table data
| Name | Required | Description | Default |
|---|---|---|---|
| app_token | Yes | Base app token | |
| dashboard_id | Yes | Dashboard block ID | |
| view_type | Yes | View type | |
| table_id | Yes | Source table ID | |
| view_id | No | Optional specific view ID | |
| title | No | View title | |
| show_toolbar | No | Show toolbar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, permission requirements, error conditions, or constraints. It only states basic creation purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource with no extraneous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 4 required parameters, the description lacks context on return values, error handling, or how this block fits into dashboard usage. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for all 7 parameters, so the schema already provides meaning. The description adds no additional parameter information, achieving baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (view block) and enumerates specific types (grid, kanban, etc.), distinguishing it from sibling tools like create_chart_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or when not to use it. Siblings like create_chart_block or create_metrics_block exist, but no differentiation is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a dashboard from a base
| Name | Required | Description | Default |
|---|---|---|---|
| app_token | Yes | Base app token | |
| dashboard_id | Yes | Dashboard block ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only indicates the deletion action but does not disclose behavioral traits such as whether the action is reversible, requires authorization, or has cascading effects. With no annotations, the description should provide this context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose. It is appropriately sized for a simple tool, though it could include one more sentence about usage without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward delete operation with two parameters, the description covers the core purpose. However, it omits context like whether the dashboard is permanently deleted or if there are dependency warnings, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for both parameters, so the schema already explains their meaning clearly. The description adds no extra semantic value beyond what's in the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('dashboard from a base'). It is specific enough to distinguish from sibling tools like create_dashboard or list_dashboards, though it could explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or any prerequisites or conditions (e.g., owner permissions, inability to undo). The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all dashboards in a base
| Name | Required | Description | Default |
|---|---|---|---|
| app_token | Yes | Base app token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as pagination, authentication requirements, performance characteristics, or whether it returns all dashboards or filtered results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose without extraneous words. It is appropriately short for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool performs a list operation with no output schema, the description lacks details about return structure, pagination, error handling, or any other behavior needed for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema adequately describes the single parameter 'app_token'. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'dashboards' with scope 'in a base', which is specific and distinguishes it from sibling tools like create_dashboard or delete_dashboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or context for choosing between list_dashboards and other dashboard tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_chart_blockcreate_dashboardcreate_metrics_blockcreate_text_blockcreate_view_blockdelete_dashboardlist_dashboardsScored across 7 tools
Each tool targets a distinct dashboard element or action: blocks (chart, metrics, text, view) and dashboard CRUD. No overlaps or ambiguity.
All tools follow a consistent verb_noun pattern (create_*, delete_*, list_*) using snake_case, making the API predictable.
7 tools is well-scoped for a dashboard builder, covering essential block types and dashboard management without unnecessary bloat.
Covers creation of main block types and basic dashboard lifecycle but lacks update and delete operations for blocks, which may force agents to recreate items.
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
Dashboards as data. Author, validate, render, and share dvt dashboards from any MCP client.
A TypeScript MCP server for Home Assistant, enabling programmatic management of entities, automati…
