一个用于 Databricks 的模型完成协议 (MCP) 服务器，可通过 MCP 协议访问 Databricks 功能。这使得基于 LLM 的工具能够与 Databricks 集群、作业、笔记本等进行交互。
MCP 协议支持：实现 MCP 协议以允许 LLM 与 Databricks 交互
Databricks API 集成：提供对 Databricks REST API 功能的访问
工具注册：将 Databricks 功能公开为 MCP 工具
异步支持：使用 asyncio 构建，可实现高效运行
Related MCP server: Databricks MCP Server
Databricks MCP 服务器公开以下工具：
list_clusters ：列出所有 Databricks 集群
create_cluster ：创建一个新的 Databricks 集群
终止Databricks 集群
get_cluster ：获取有关特定 Databricks 集群的信息
start_cluster ：启动已终止的 Databricks 集群
list_jobs ：列出所有 Databricks 作业
run_job ：运行 Databricks 作业
list_notebooks ：列出工作区目录中的笔记本
export_notebook ：从工作区导出笔记本
list_files ：列出 DBFS 路径中的文件和目录
执行SQL 语句
Python 3.10 或更高版本
uv包管理器（推荐用于 MCP 服务器）
如果尚未安装uv ，请安装它：
# MacOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows (in PowerShell)
irm https://astral.sh/uv/install.ps1 | iex安装后重新启动终端。
克隆存储库：
git clone https://github.com/JustTryAI/databricks-mcp-server.git
cd databricks-mcp-server使用uv设置项目：
# Create and activate virtual environment
uv venv
# On Windows
.\.venv\Scripts\activate
# On Linux/Mac
source .venv/bin/activate
# Install dependencies in development mode
uv pip install -e .
# Install development dependencies
uv pip install -e ".[dev]"设置环境变量：
# Windows
set DATABRICKS_HOST=https://your-databricks-instance.azuredatabricks.net
set DATABRICKS_TOKEN=your-personal-access-token
# Linux/Mac
export DATABRICKS_HOST=https://your-databricks-instance.azuredatabricks.net
export DATABRICKS_TOKEN=your-personal-access-token您还可以基于.env.example模板创建.env文件。
要启动 MCP 服务器，请运行：
# Windows
.\start_mcp_server.ps1
# Linux/Mac
./start_mcp_server.sh这些包装脚本将执行位于scripts目录中的实际服务器脚本。服务器将启动并准备好接受 MCP 协议连接。
您也可以直接从脚本目录运行服务器脚本：
# Windows
.\scripts\start_mcp_server.ps1
# Linux/Mac
./scripts/start_mcp_server.sh该存储库包含用于快速查看 Databricks 资源的实用程序脚本：
# View all clusters
uv run scripts/show_clusters.py
# View all notebooks
uv run scripts/show_notebooks.pydatabricks-mcp-server/
├── src/ # Source code
│ ├── __init__.py # Makes src a package
│ ├── __main__.py # Main entry point for the package
│ ├── main.py # Entry point for the MCP server
│ ├── api/ # Databricks API clients
│ ├── core/ # Core functionality
│ ├── server/ # Server implementation
│ │ ├── databricks_mcp_server.py # Main MCP server
│ │ └── app.py # FastAPI app for tests
│ └── cli/ # Command-line interface
├── tests/ # Test directory
├── scripts/ # Helper scripts
│ ├── start_mcp_server.ps1 # Server startup script (Windows)
│ ├── run_tests.ps1 # Test runner script
│ ├── show_clusters.py # Script to show clusters
│ └── show_notebooks.py # Script to show notebooks
├── examples/ # Example usage
├── docs/ # Documentation
└── pyproject.toml # Project configuration请参阅project_structure.md来了解项目结构的更详细视图。
Python 代码遵循 PEP 8 风格指南，每行最大长度为 100 个字符
使用 4 个空格缩进（不使用制表符）
对字符串使用双引号
所有类、方法和函数都应该有 Google 风格的文档字符串
除测试外，所有代码都需要类型提示
该项目使用以下 linting 工具：
# Run all linters
uv run pylint src/ tests/
uv run flake8 src/ tests/
uv run mypy src/该项目使用 pytest 进行测试。要运行测试：
# Run all tests with our convenient script
.\scripts\run_tests.ps1
# Run with coverage report
.\scripts\run_tests.ps1 -Coverage
# Run specific tests with verbose output
.\scripts\run_tests.ps1 -Verbose -Coverage tests/test_clusters.py您还可以直接使用 pytest 运行测试：
# Run all tests
uv run pytest tests/
# Run with coverage report
uv run pytest --cov=src tests/ --cov-report=term-missing该项目的目标是最低代码覆盖率达到 80%。
API 文档是使用 Sphinx 生成的，可以在docs/api目录中找到
所有代码都包含 Google 风格的文档字符串
请参阅examples/目录以获取使用示例
查看examples/目录以获取用法示例。要运行示例，请执行以下操作：
# Run example scripts with uv
uv run examples/direct_usage.py
uv run examples/mcp_client_usage.py欢迎贡献代码！欢迎提交 Pull 请求。
确保您的代码遵循项目的编码标准
为任何新功能添加测试
根据需要更新文档
提交前验证所有测试均已通过
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅 LICENSE 文件。
Create a new Databricks cluster with parameters: cluster_name (required), spark_version (required), node_type_id (required), num_workers, autotermination_minutes
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a cluster but doesn't describe what happens after creation (e.g., whether it starts automatically, costs involved, time to provision, or error handling). For a mutation tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
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, efficient sentence that front-loads the core action and lists parameters without unnecessary details. It avoids redundancy and wastes no words, though it could benefit from slight structuring (e.g., separating parameter explanations) for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating a Databricks cluster (a mutation operation with no annotations, no output schema, and a nested input schema with 0% coverage), the description is incomplete. It lacks information on behavioral outcomes, error cases, return values, and how it fits with sibling tools, making it insufficient for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and uses a generic 'params' object, so the description must compensate. It lists specific parameters (cluster_name, spark_version, etc.) and marks some as required, adding meaningful semantics beyond the schema. However, it doesn't explain what these parameters mean (e.g., what 'spark_version' entails or how 'num_workers' affects the cluster), leaving gaps in understanding.
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 a new Databricks cluster') and resource ('Databricks cluster'), making the purpose unambiguous. However, it doesn't explicitly differentiate this tool from sibling tools like 'start_cluster' or 'get_cluster', which would require more specific context about when to create versus start an existing cluster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing permissions or a workspace setup), compare it to siblings like 'start_cluster' (for existing clusters) or 'run_job' (which might involve clusters), or specify scenarios where creation is appropriate versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a SQL statement with parameters: statement (required), warehouse_id (required), catalog (optional), schema (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Execute a SQL statement') but doesn't cover critical traits like whether it's read-only or destructive, authentication needs, rate limits, error handling, or output format. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and lists parameters concisely. There's no wasted text, making it easy to parse, though it could benefit from more structured detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing SQL (a potentially destructive operation), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks information on behavior, results, error cases, and how it fits with sibling tools, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description lists parameters (statement, warehouse_id, catalog, schema) but doesn't explain their semantics beyond being required or optional. It adds some value by naming parameters, but fails to detail their meanings, formats, or constraints, which is insufficient given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Execute a SQL statement with parameters', which provides a clear verb ('Execute') and resource ('SQL statement'), but it's somewhat vague about the exact purpose (e.g., what database or system it targets) and doesn't distinguish it from potential siblings like 'run_job' or 'export_notebook'. It's adequate but lacks specificity.
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 mentions parameters but offers no guidance on when to use this tool versus alternatives like 'run_job' or 'list_jobs', nor does it specify prerequisites or contexts for SQL execution. It's a basic statement of function without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a notebook from the workspace with parameters: path (required), format (optional, one of: SOURCE, HTML, JUPYTER, DBC)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action 'Export' but doesn't specify whether this is a read-only operation, if it requires permissions, what happens to the original notebook, or any rate limits. This leaves significant gaps for a tool that likely involves data extraction.
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, efficient sentence that front-loads the purpose and key parameters. It avoids unnecessary words, though it could be slightly more structured by separating usage notes from parameter details.
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, 0% schema coverage, no output schema, and a nested parameter structure, the description is incomplete. It doesn't explain the return value, error conditions, or how the 'params' object should be structured, making it inadequate for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some parameter details (path is required, format is optional with enum values), but with 0% schema description coverage and a nested 'params' object in the schema, it doesn't fully compensate. It provides basic semantics but lacks depth on structure or constraints beyond what's minimally stated.
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 ('Export') and resource ('a notebook from the workspace'), making the purpose understandable. However, it doesn't differentiate this tool from potential sibling tools like 'list_notebooks' or 'run_job' beyond the export function, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'list_notebooks' and 'run_job' available, there's no indication of prerequisites, context, or exclusions for choosing export_notebook over other notebook-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a specific Databricks cluster with parameter: cluster_id (required)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'Get information' operation which implies read-only behavior, but doesn't disclose any behavioral traits like whether it requires specific permissions, what happens if the cluster doesn't exist, rate limits, or what format the information is returned in. The description is minimal and leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with just one sentence that states the purpose and mentions the required parameter. It's front-loaded with the core functionality. While it could be more informative, every word serves a purpose and there's no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of cluster operations, no annotations, no output schema, and minimal parameter documentation, the description is incomplete. It doesn't explain what information is returned, how to interpret results, error conditions, or how this differs from other cluster tools. For a tool that presumably returns detailed cluster configuration and status information, this description leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% with 1 parameter, and the description mentions 'cluster_id (required)' which adds some semantic meaning beyond the schema. However, it doesn't explain what format the cluster_id should be in, where to find it, or provide any examples. For a single parameter tool with zero schema coverage, this minimal information is insufficient to compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get information about a specific Databricks cluster' which provides a clear verb ('Get information') and resource ('Databricks cluster'), but it doesn't distinguish this from sibling tools like 'list_clusters' or 'start_cluster'. It's vague about what specific information is retrieved compared to alternatives.
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 like 'list_clusters' or 'start_cluster'. It mentions the required parameter 'cluster_id' but doesn't explain when this tool is appropriate versus other cluster-related operations available in the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Databricks clusters
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. It doesn't indicate whether this is a read-only operation, what permissions are required, whether there are rate limits, pagination behavior, or what the return format looks like. For a tool with zero annotation coverage, this is completely inadequate.
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 extremely concise - a single sentence with no wasted words. It's front-loaded with the core purpose. While it's too brief to be helpful, it earns full marks for conciseness as every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (listing clusters in Databricks), lack of annotations, no output schema, and 0% parameter coverage, the description is completely inadequate. It doesn't explain what information is returned, how results are structured, whether there are limitations, or any operational context needed to use the tool 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?
The input schema has 1 parameter with 0% description coverage, and the tool description provides absolutely no information about parameters. The description doesn't mention what 'params' should contain, what filtering options are available, or any parameter semantics. With low schema coverage and no compensation in the description, this is a critical gap.
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 resource ('all Databricks clusters'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_cluster' (which presumably retrieves a single cluster) or 'list_jobs'/'list_notebooks' (which list different resource types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'list_clusters' versus 'get_cluster' (for retrieving a single cluster) or other listing tools like 'list_jobs'. There's no information about prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and directories in a DBFS path with parameter: dbfs_path (required)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but doesn't disclose behavioral traits such as pagination, rate limits, authentication needs, error handling, or what happens with invalid paths. For a tool with no annotations, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states the purpose and parameter. It's front-loaded with the core action and avoids unnecessary details. However, it could be slightly more structured by separating purpose from parameter explanation.
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, 0% schema coverage, no output schema, and 1 parameter with nested objects, the description is incomplete. It lacks details on return values, error conditions, and behavioral context, making it inadequate for a tool with these complexities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with 1 parameter documented only as 'params' of type 'object' in the schema. The description adds that it's 'dbfs_path (required)', providing basic semantics, but doesn't explain format, constraints, or examples. This partially compensates but is insufficient given the low schema coverage.
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 resource ('files and directories'), specifying the scope as 'in a DBFS path'. It distinguishes from siblings like list_clusters or list_notebooks by focusing on DBFS files. However, it doesn't explicitly differentiate from potential similar file-listing tools that might exist elsewhere.
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 mentions the parameter but doesn't indicate prerequisites, typical use cases, or when other tools like list_notebooks might be more appropriate. It's purely functional without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Databricks jobs
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List all Databricks jobs' implies a read-only operation, but it doesn't specify whether this requires authentication, returns paginated results, includes metadata like job status or owner, or has any rate limits. For a listing tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words, front-loading the essential information with zero wasted words. Every word earns its place by specifying the action ('List'), scope ('all'), resource type ('Databricks jobs'), making it efficiently structured despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a job listing operation with no annotations, no output schema, and 0% parameter documentation, the description is incomplete. It doesn't explain what information is returned (e.g., job IDs, names, statuses), how results are formatted, or any constraints. For a tool that likely returns structured data about jobs, this minimal description leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage with one required parameter 'params' as an object type. The description provides no information about what parameters are accepted (e.g., filters for job name, status, owner, or pagination controls). Since schema coverage is 0%, the description should compensate but fails to do so, leaving parameters completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all Databricks jobs'), making the tool's purpose immediately understandable. It distinguishes this from sibling tools like 'run_job' or 'create_cluster' by focusing on listing rather than execution or creation. However, it doesn't specify if this includes archived, active, or all job states, which would make it a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention whether to use 'list_jobs' versus 'run_job' for job management, or how it relates to other listing tools like 'list_clusters' or 'list_notebooks'. There's no context about prerequisites, permissions needed, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List notebooks in a workspace directory with parameter: path (required)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While it mentions the tool lists notebooks, it doesn't disclose any behavioral traits - no information about pagination, sorting, filtering capabilities, authentication requirements, rate limits, or what happens when the path doesn't exist. For a listing tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise - a single sentence that states the purpose and mentions the required parameter. There's no wasted language, though it could benefit from being more informative while maintaining brevity.
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 zero annotation coverage, 0% schema description coverage, no output schema, and a parameter that's a nested object with no documentation, the description is insufficient. It doesn't explain what 'notebooks' are in this context, what format the output takes, or how to interpret the path parameter - leaving significant gaps for an AI 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 description coverage is 0%, and the description only mentions 'path (required)' without explaining what format the path should take, what workspace/directory structure it references, or any constraints. With 1 parameter that's completely undocumented in both schema and description, the description adds minimal value beyond stating the parameter exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'List notebooks in a workspace directory', which provides a clear verb ('List') and resource ('notebooks'). However, it doesn't distinguish this tool from potential siblings like 'list_files' or 'list_clusters' - it's unclear what makes notebooks different from other file types or resources in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_files' and 'list_clusters' available, there's no indication of whether this tool is for a specific notebook format, workspace context, or how it differs from general file listing operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Databricks job with parameters: job_id (required), notebook_params (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions parameters without behavioral traits. It doesn't disclose if this is a read/write operation, requires permissions, has side effects (e.g., resource consumption), rate limits, or what happens during execution (e.g., async/sync). This is inadequate for a tool that likely triggers job runs.
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 brief and front-loaded with the main action, using only one sentence. However, it could be more structured by separating purpose from parameter details, but it avoids unnecessary verbosity, earning a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (likely a job execution tool with no annotations, 0% schema coverage, and no output schema), the description is incomplete. It lacks details on behavior, return values, error handling, and integration with siblings, making it insufficient for effective agent use in this 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 description coverage is 0%, and the description adds minimal value beyond the schema. It mentions 'job_id (required), notebook_params (optional)', but the schema has a single nested 'params' object without details. The description doesn't explain parameter formats, constraints, or how they map to the schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Run a Databricks job') and mentions parameters, which gives a vague purpose. However, it doesn't specify what 'run' entails (e.g., execution, triggering, monitoring) or differentiate from siblings like 'execute_sql' or 'list_jobs', leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., job must exist), exclusions (e.g., not for ad-hoc queries), or compare to siblings like 'execute_sql' for different execution contexts, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a terminated Databricks cluster with parameter: cluster_id (required)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is to start a cluster, implying a mutation operation, but fails to disclose critical traits such as permissions required, whether it's idempotent, potential side effects (e.g., costs, time to start), or response format. This leaves significant gaps for a tool that performs a state change.
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, straightforward sentence that efficiently conveys the core action and required parameter without unnecessary words. It's appropriately sized for the tool's complexity, though it could be more front-loaded with key details like behavioral traits.
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 (a mutation operation to start a cluster), lack of annotations, no output schema, and low schema description coverage, the description is incomplete. It omits essential context such as behavioral implications, error conditions, or how to verify success, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description only mentions 'cluster_id (required)' without explaining what this parameter represents (e.g., a specific cluster identifier), its format, or how to obtain it. Given the low coverage and the presence of a nested object 'params' in the schema, the description adds minimal value beyond stating the parameter name, failing to compensate for the schema's lack of detail.
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 ('Start') and resource ('a terminated Databricks cluster'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'create_cluster' (which creates new clusters) or 'terminate_cluster' (which stops clusters), missing explicit sibling distinction that would warrant a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by mentioning the required parameter 'cluster_id' but offers no explicit context on when to use this tool versus alternatives like 'create_cluster' for new clusters or 'get_cluster' for checking status. There's no mention of prerequisites (e.g., cluster must be terminated) or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Terminate a Databricks cluster with parameter: cluster_id (required)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose if termination is destructive, irreversible, requires specific permissions, has side effects, or what happens post-termination, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. However, it's slightly under-specified given the tool's complexity, as it could benefit from more detail without sacrificing brevity.
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 destructive mutation tool with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It lacks critical context like behavioral traits, parameter details, and usage scenarios, making it incomplete for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'cluster_id (required)' without explaining what it is, its format, or where to find it. This adds minimal value beyond the schema's required 'params' object, failing to compensate for the coverage gap.
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 ('Terminate') and resource ('a Databricks cluster'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_cluster' or 'start_cluster' beyond the obvious action difference, missing explicit comparison.
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. It mentions a required parameter but doesn't specify prerequisites, conditions for termination, or when to choose this over other cluster-related tools like 'start_cluster' or 'get_cluster'.
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.
create_clusterexecute_sqlexport_notebookget_clusterlist_clusterslist_fileslist_jobslist_notebooksrun_jobstart_clusterterminate_clusterScored across 11 tools
Each tool has a distinct purpose with clear boundaries: cluster management (create, get, list, start, terminate), SQL execution, notebook operations (export, list), file listing, and job operations (list, run). No overlapping functionality exists, making tool selection straightforward for an agent.
All tools follow a consistent verb_noun pattern (e.g., create_cluster, execute_sql, list_files) using snake_case throughout. This predictable naming convention enhances readability and usability for agents.
With 11 tools, the server is well-scoped for Databricks operations, covering clusters, SQL, notebooks, files, and jobs. Each tool serves a clear purpose without redundancy, making the count appropriate for the domain.
The toolset provides strong coverage for core Databricks workflows, including cluster lifecycle, SQL execution, notebook/file management, and job operations. Minor gaps exist, such as missing notebook creation or job update tools, but agents can work around these with available operations.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
