This MCP server lets AI assistants discover, explain, and safely execute dbatools PowerShell commands.
Search and list dbatools commands by verb, noun, keyword, risk level, and result limit.
Retrieve full normalized command help, including parameters and examples.
Execute dbatools commands with validated parameters, optional property selection, SQL authentication, and structured JSON output.
Require explicit confirmation for change/destructive commands when safe mode is enabled, with risk annotations exposed to MCP clients.
Check PowerShell/dbatools installation, help-index status, and version alignment.
Browse command help as MCP resources via dbatools://command/{name}.
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., "@dbatools-mcp-server list all commands related to backup"
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.
A Model Context Protocol (MCP) server for the dbatools PowerShell module.
Exposes dbatools commands as MCP tools so AI assistants (GitHub Copilot, Claude, etc.) can discover, explain, and execute dbatools commands directly — with all metadata sourced from dbatools' own comment-based help.
list_dbatools_commands — search commands by verb, noun, keyword, or risk level
get_dbatools_command_help — full normalized help (synopsis, parameters, examples) from Get-Help -Full
invoke_dbatools_command — execute any dbatools command with safe parameter validation, risk gating, and structured JSON output
check_dbatools_environment — verify PowerShell + dbatools installation, index freshness, and version alignment
Tool annotations — each tool declares readOnlyHint / destructiveHint / idempotentHint / openWorldHint so MCP clients (e.g. VS Code) can surface risk in the UI before a tool is even called
Resources — browse dbatools://command/{name} to read any command's full normalized help as structured JSON, independent of the chat-oriented tool responses
Persistent PowerShell session — invoke_dbatools_command reuses one long-lived pwsh process with dbatools pre-imported instead of spawning (and re-importing dbatools into) a fresh process on every call
Version mismatch detection — warns when installed dbatools version differs from the indexed version
Safe mode — non-readonly commands require explicit confirm: true to execute
SQL Authentication support — pass SqlCredential: { username, password } for SQL auth instances
Related MCP server: mcp-sqlserver
Node.js 20+
PowerShell 7+ (pwsh)
dbatools PowerShell module
Install-Module dbatools -Scope CurrentUser# 1. Clone the repo
git clone https://github.com/Dataplat/dbatools-mcp-server.git
cd dbatools-mcp-server
# 2. Install Node dependencies
npm install
# 3. Generate the help index from your local dbatools installation
npm run refresh-help
# 4. Build
npm run buildThen open the folder in VS Code — the .vscode/mcp.json file automatically registers the MCP server.
The included .vscode/mcp.json registers the server as a local STDIO MCP server.
Open this folder in VS Code and the server will appear in the GitHub Copilot MCP panel.
{
"servers": {
"dbatools": {
"type": "stdio",
"command": "node",
"args": ["${workspaceFolder}/dist/server.js"],
"env": {
"DBATOOLS_SAFE_MODE": "true",
"MAX_OUTPUT_ROWS": "100",
"COMMAND_TIMEOUT_SECONDS": "60"
}
}
}
}All settings are controlled via environment variables (set in .vscode/mcp.json or your shell):
Variable | Default | Description |
|
| Path to PowerShell executable |
|
| When |
|
| Maximum rows returned per command execution |
|
| Seconds before PowerShell process is killed |
|
| When |
The help index (generated/dbatools-help.json) is generated from your locally installed dbatools module.
Re-run whenever dbatools is updated:
Update-Module dbatools -Scope CurrentUser
npm run refresh-helpThe server detects version mismatches at runtime and warns you when the index is stale.
Commands are automatically classified by verb:
Risk Level | Verbs | Behavior |
| Get, Test, Find, Compare, … | Always allowed |
| Set, New, Add, Copy, Enable, … | Requires |
| Remove, Drop, Disable, Reset, … | Requires |
Each risk tier maps to standard MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), so compatible clients can surface risk in their UI before a tool is even invoked. invoke_dbatools_command is a generic dispatcher that can run any command, so its annotation conservatively reflects the worst case (destructiveHint: true) — the actual per-command risk is still enforced at runtime by the safe-mode gate.
Besides the four tools, the server exposes every indexed command as an MCP resource at dbatools://command/{name} (e.g. dbatools://command/Get-DbaDatabase), returning the same normalized help record as structured JSON — useful for clients that browse/ground on resources rather than calling a tool. The browsable resource list excludes PowerShell aliases (e.g. Attach-DbaDatabase, an alias for Mount-DbaDatabase) since they just forward to another command's help.
By default, invoke_dbatools_command reuses a single long-lived pwsh process with dbatools pre-imported, instead of spawning a fresh process (and re-importing dbatools) on every call. This removes the ~1-2s+ process-startup and module-import cost from every invocation after the first.
A couple of things to be aware of:
Crash/timeout recovery: if a command times out or the session process crashes, it is killed and discarded; the next call transparently starts a fresh session (paying the import cost once more). The call that triggered the failure is not automatically retried.
Cross-call state: dbatools caches some state (e.g. SMO connections via Connect-DbaInstance) within a PowerShell session. With a persistent session, that caching is now visible across tool calls within one MCP server run, where previously every call was fully isolated. Each individual script still runs in its own scope, so plain variables never leak between calls — only dbatools' own internal caching behavior is affected.
Set DBATOOLS_PERSISTENT_SESSION=false to disable this and go back to one fresh process per call.
For SQL-auth-only instances (e.g. Docker), pass credentials via the SqlCredential parameter:
{
"SqlInstance": "localhost,1433",
"SqlCredential": { "username": "<SqlLogin>", "password": "YourPassword" }
}dbatools-mcp-server/
├── src/
│ ├── server.ts # MCP server entry point, tool/resource definitions
│ ├── powershell.ts # One-shot PowerShell process runner, health checks, version detection
│ ├── powershell-session.ts # Persistent PowerShell session (long-lived process, dbatools pre-imported)
│ ├── help-indexer.ts # Help manifest loader and command search
│ ├── tool-registry.ts # Risk classification, tool annotations, safe argument builder
│ └── types.ts # Shared TypeScript interfaces
├── scripts/
│ └── refresh-help.ps1 # Generates generated/dbatools-help.json
├── generated/ # Help index (gitignored, generated locally)
├── .vscode/
│ └── mcp.json # VS Code MCP local server registration
└── dist/ # Compiled output (gitignored)Contributions are welcome! Please open an issue first for significant changes.
This project follows the same community spirit as dbatools.
MIT — © 2026 DataPlat contributors
Verify that PowerShell and the dbatools module are installed and report the help-index status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld, so safety is covered structurally. The description adds that it checks installation state and reports help-index status, a useful behavioral detail, but says nothing about failure modes or output shape.
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?
One sentence, front-loaded with the verb and the two things verified, with no filler. Every clause 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?
For a parameterless diagnostic with annotations covering safety and no output schema, the description is nearly sufficient. A brief note on what the report contains (e.g., installed/version/help-index accuracy) would close the remaining gap.
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?
Zero parameters, so there is nothing for the description to disambiguate; the baseline applies. The description correctly signals a no-argument check operation.
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?
Specific verb ('Verify') with named resources (PowerShell, dbatools module) and a stated output focus (help-index status). It is clearly distinguishable from listing, help-lookup, and invocation siblings, though it doesn't name any of 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?
Usage is implied: this is a pre-flight/environment sanity check. There is no explicit when-to-use, when-not-to-use, or reference to the alternative tools, so the agent must infer that it precedes invoke_dbatools_command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full normalized help for a specific dbatools command, including parameters and examples sourced from comment-based help.
| Name | Required | Description | Default |
|---|---|---|---|
| commandName | Yes | Exact command name, e.g. Get-DbaDatabase |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing the return content — normalized help with parameters and examples drawn from comment-based help — which tells the agent what to expect back.
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?
A single well-formed sentence with the action and the return payload front-loaded. Nothing redundant or padded.
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 simple closed-world read with a fully documented single param and no output schema, the description says what comes back and where it is sourced from. The only minor gap is behavior for an unknown or misspelled command name (error vs empty result).
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?
There is one parameter at 100% schema coverage with an inline example ('Get-DbaDatabase'), so the schema carries the semantics. The description only restates that a specific command name is needed and adds no format or lookup guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Get the full normalized help for a specific dbatools command', plus the payload it returns (parameters and examples). It is distinct from list_dbatools_commands and invoke_dbatools_command in practice, but it never names those siblings to make the contrast explicit.
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?
Usage is only implied: the required exact command name suggests you must already know the command, presumably found via list_dbatools_commands, but the description never says so. No when-not-to-use or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a dbatools command via PowerShell and return structured JSON output.
SAFETY: For any destructive or change command (Remove, Drop, Disable, Reset, etc.), always explain the consequences to the user and ask for explicit confirmation before running. Only proceed with confirm:true if the user has clearly confirmed their intent. Respect DBATOOLS_SAFE_MODE: never bypass safety checks. For any command that modifies or deletes data, double-check with the user before proceeding. Show the exact command and output for transparency. Non-readonly commands require confirm:true when safe mode is enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Set to true to allow execution of change/destructive commands (required when safeMode is on) | |
| parameters | No | Key-value map of parameters. Strings, numbers, and booleans map directly to PowerShell parameters. For SQL authentication pass SqlCredential as an object: { "username": "sa", "password": "secret" }. Example: { "SqlInstance": "localhost,2022", "SqlCredential": { "username": "sa", "password": "P@ssw0rd" } } | |
| commandName | Yes | Exact dbatools command name to execute, e.g. Get-DbaDatabase | |
| selectProperties | No | List of property names to select from the output (e.g. ['Name', 'Status', 'SizeMB']). Use this to reduce output size for commands that return complex objects like SMO database or login objects. When omitted, all properties are returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, openWorldHint=true, and readOnlyHint=false. The description adds substantial procedural safety context: it explains the confirm:true workflow, references DBATOOLS_SAFE_MODE, tells the agent to explain consequences before destructive commands, and requires showing the exact command and output for transparency.
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 front-loaded with its purpose and then provides safety guidance, which is appropriate for a dangerous generic executor. It is somewhat repetitive about confirmation and double-checking, but the redundancy is arguably justified by the destructive nature of the tool.
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 generic execution wrapper with four parameters, full schema coverage, and explicit destructive/open-world annotations, the description is complete enough to call the tool safely. It omits explicit routing to sibling discovery/help tools, which is a minor contextual gap given that arbitrary dbatools command names and parameters must be known in advance.
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 schema already documents commandName, parameters, selectProperties, and confirm in detail. The description reinforces the confirm semantics and safe-mode condition but adds little about the other parameters or the nested parameter map beyond what the schema provides.
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 a specific verb and resource: execute a dbatools command via PowerShell and return structured JSON. It is clearly the execution tool versus the sibling help/list/check tools, but it does not explicitly name those siblings or explain the division of labor.
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 gives clear operational context for when confirmation is required and strongly warns against running destructive commands without explicit user approval. It does not, however, mention when to use sibling tools such as list_dbatools_commands or get_dbatools_command_help before invoking a command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and list dbatools commands. Filter by verb, noun, keyword, or risk level.
| Name | Required | Description | Default |
|---|---|---|---|
| noun | No | Noun fragment to match (e.g. Database, Login, AgentJob) | |
| verb | No | PowerShell verb (e.g. Get, Set, New, Remove, Test) | |
| limit | No | Maximum number of results (default 50, max 200) | |
| keyword | No | Keyword to search in name, synopsis, and description | |
| riskLevel | No | Filter by risk tier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only that filtering is supported, saying nothing about result ordering, pagination beyond the limit cap, or what each result entry contains.
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?
Two compact sentences with the core action front-loaded and the filter surface immediately after. No filler, no repetition of name or title.
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 all five optional parameters fully documented in the schema, no output schema, and annotations covering safety and world scope, the description is nearly sufficient for correct invocation. It stops just short by not indicating the shape or ordering of returned command entries.
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%, with per-parameter descriptions, examples (Database, Login, AgentJob; Get, Set, New), defaults and the riskLevel enum all documented in the schema. The description merely restates the four filter names, adding no matching semantics such as partial/substring behavior.
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?
States a specific verb+resource ('search and list dbatools commands') and names the four filter dimensions, so an agent immediately knows this is the discovery tool. It does not explicitly contrast itself with get_dbatools_command_help or invoke_dbatools_command, leaving sibling differentiation to the tool names.
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 phrase 'Search and list' implies a discovery-then-act workflow, and the filter list hints at narrowing before invoking. However, there is no explicit statement of when to choose this over get_dbatools_command_help or when to skip listing and invoke directly, and no exclusions or prerequisites.
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.
v0.5.0check_dbatools_environmentget_dbatools_command_helpinvoke_dbatools_commandlist_dbatools_commandsScored across 4 tools
Each tool maps to a distinct phase of the workflow: environment verification, command discovery, documentation lookup, and execution. list_dbatools_commands (search) versus get_dbatools_command_help (full help for one known command) are clearly separated by their descriptions.
All four tools follow the same snake_case verb_dbatools_noun pattern: get_, list_, invoke_, check_. The domain prefix is applied uniformly, making the set predictable.
Four tools cover the essential wrapper surface (discover, inspect, run, verify) without redundancy. It is on the lean side, but for a single-module gateway that is reasonable rather than a mismatch.
Discovery, help, execution, and environment validation give a complete basic lifecycle with no dead ends. Minor gaps exist, such as refreshing/rebuilding the help index or batch invocation, but agents can work around them via invoke_dbatools_command.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
MCP server exposing the Backtest360 engine API as tools for AI agents.
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.
