The Arpeio MCP server provides a unified interface for AI assistants to build, preview, and execute high-performance data operations across four Arpe.io CLI tools — no binaries required for command-building.
FastBCP (Database Export) — 3 tools
Preview export commands for databases (SQL Server, PostgreSQL, Oracle, MySQL, etc.) to formats like CSV, Parquet, JSON, XLSX, with auto-suggested parallelism and support for local, S3, Azure, and GCS targets
Execute pre-built export commands
Get supported formats, parallelism recommendations, and workflow guidance
FastTransfer (Database-to-Database Transfer) — 3 tools
Preview high-performance transfer commands between databases (e.g., PostgreSQL → SQL Server, Oracle → DuckDB)
Execute pre-built transfer commands
Get supported source/target combinations, parallelism recommendations, and workflow guidance
LakeXpress (Database-to-Cloud Lake Pipelines) — 3 tools
Preview commands for the full pipeline lifecycle: init, config create/delete/list, sync, run, status, cleanup, and lock management
Execute pre-built pipeline commands
Get capabilities, supported storage backends, publish targets, and workflow sequences
MigratorXpress (Cross-Platform Database Migration) — 4 tools
Preview migration commands covering DDL translation, table creation, data transfer, diffs, and constraint copying (Oracle, PostgreSQL, SQL Server, Netezza, MySQL)
Execute pre-built migration commands
Validate credential JSON auth files before running migrations
Get supported platforms, task sequences, and workflow guidance
Meta / Discovery Tools — 4 tools
Check installation status of all Arpe.io CLI tools
Get quick-start guidance by describing a use case in plain English
Search Arpe.io documentation and blog for parameters, examples, and best practices
Retrieve release notes for any product, optionally filtered by version
Key design features:
No binaries needed for command building/preview; execution tools require the respective binary
All execute tools require explicit confirmation=true as a safety gate
Structured JSON + human-readable markdown output for programmatic chaining
Typical workflow: *_preview_* → *_execute_* (2 calls)
Allows GitHub Copilot in VS Code to build, preview, and execute high-performance data commands (database export, transfer, pipeline, migration) using Arpe.io data tools.
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., "@arpeio-mcp export my PostgreSQL database to S3"
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.
Unified MCP server for Arpe.io data tools — build, preview, and execute high-performance data commands through AI assistants.
Tool | Description |
FastBCP | High-performance parallel database export to files and cloud |
FastTransfer | High-performance parallel data transfer between databases |
LakeXpress | Automated database-to-cloud data pipeline as Parquet |
MigratorXpress | Cross-platform database migration with parallel transfer |
No binaries required. All tools work in command builder mode out of the box — command building, preview, and informational tools work without any Arpe.io binary installed. To enable execution, download the binaries from arpe.io and set the corresponding
*_PATHenvironment variables.
Related MCP server: MigratorXpress MCP Server
A hosted instance is available at https://arpe-io-arpeio-mcp.hf.space/sse — no installation required. For local installation with execution support, use the stdio transport via pip install arpeio-mcp.
ChatGPT | Claude Code | Claude Desktop | Cursor | Gemini CLI | HuggingChat | Kiro IDE | Le Chat (Mistral) | VS Code | Windsurf
Available for paid plans only (Plus, Pro, Team, and Enterprise).
Open ChatGPT in your browser, go to Settings > Apps and connectors.
Open Advanced settings and enable Developer mode.
Go to Connectors > Browse connectors > Add a new connector.
Set the URL to https://arpe-io-arpeio-mcp.hf.space/sse and save.
claude mcp add --transport sse arpeio https://arpe-io-arpeio-mcp.hf.space/sseOr for local installation with execution support:
pip install arpeio-mcp
claude mcp add arpeio arpeio-mcpAdd the following to your Claude Desktop configuration file:
Linux: ~/.config/Claude/claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"arpeio": {
"command": "npx",
"args": [
"mcp-remote",
"https://arpe-io-arpeio-mcp.hf.space/sse"
]
}
}
}{
"mcpServers": {
"arpeio": {
"command": "arpeio-mcp",
"env": {
"FASTBCP_PATH": "/path/to/FastBCP",
"FASTTRANSFER_PATH": "/path/to/FastTransfer",
"LAKEXPRESS_PATH": "/path/to/LakeXpress",
"MIGRATORXPRESS_PATH": "/path/to/MigratorXpress"
}
}
}
}Open Cursor Settings and search for "MCP".
Add a new MCP server with the following configuration:
{
"mcpServers": {
"arpeio": {
"url": "https://arpe-io-arpeio-mcp.hf.space/sse"
}
}
}Add the following to your ~/.gemini/settings.json file:
{
"mcpServers": {
"arpeio": {
"uri": "https://arpe-io-arpeio-mcp.hf.space/sse"
}
}
}In the chat interface, click the + icon, select MCP Servers, then Manage MCP Servers.
Click Add Server.
Set the Server Name to Arpe.io and the Server URL to https://arpe-io-arpeio-mcp.hf.space/sse.
Click Add Server and verify the health check shows Connected.
Add the following to your Kiro MCP configuration file (.kiro/settings/mcp.json in your workspace):
{
"mcpServers": {
"arpeio": {
"url": "https://arpe-io-arpeio-mcp.hf.space/sse"
}
}
}Available on all plans, including free.
Go to Intelligence > Connectors.
Click Add connector > Custom MCP Connector.
Set the name to Arpe.io and the URL to https://arpe-io-arpeio-mcp.hf.space/sse.
Leave authentication disabled and click Create.
Add the following to your VS Code MCP configuration. Run MCP: Open User Configuration from the Command Palette to open it.
Linux: ~/.config/Code/User/mcp.json
macOS: ~/Library/Application Support/Code/User/mcp.json
Windows: %APPDATA%\Code\User\mcp.json
{
"servers": {
"arpeio": {
"url": "https://arpe-io-arpeio-mcp.hf.space/sse",
"type": "sse"
}
}
}Add the following to your Windsurf configuration file:
Linux: ~/.codeium/windsurf/mcp_config.json
macOS: ~/.codeium/windsurf/mcp_config.json
Windows: %USERPROFILE%\.codeium\windsurf\mcp_config.json
{
"mcpServers": {
"arpeio": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://arpe-io-arpeio-mcp.hf.space/sse"
]
}
}
}For full execution support (not just command building), install locally:
pip install arpeio-mcpThen configure your AI assistant to use the arpeio-mcp command (stdio transport) with optional binary paths — see the Claude Desktop local configuration for an example.
Variable | Description | Required |
| Path to FastBCP binary | No |
| Path to FastTransfer binary | No |
| Path to LakeXpress binary | No |
| Path to MigratorXpress binary | No |
| FastBCP directory for LakeXpress | No |
| FastTransfer directory for MigratorXpress | No |
| Per-tool execution timeout (seconds) | No |
| Per-tool log directory | No |
| Logging level (DEBUG/INFO/WARNING/ERROR) | No |
Read-only advisory tools were consolidated into one *_info tool per product (with an action enum) and per-product release-notes tools were merged into a single arpe_release_notes. Auto-parallelism is now suggested inside preview so the typical workflow is 2 calls (preview → execute) instead of 4.
fastbcp_info — Read-only advisory: action="formats" | "parallelism" | "workflow" | "version"
fastbcp_preview_export — Validate parameters and render the command (auto-suggests parallelism when method is omitted)
fastbcp_execute_export — Run the export
fasttransfer_info — Read-only advisory: action="combinations" | "parallelism" | "workflow" | "version"
fasttransfer_preview_transfer — Validate parameters and render the command (auto-suggests parallelism)
fasttransfer_execute_transfer — Run the transfer
lakexpress_info — Read-only advisory: action="capabilities" | "workflow" | "version"
lakexpress_preview_command — Build any LakeXpress command (lxdb_*, config_*, sync, sync[export], sync[publish], run, status, cleanup). On v0.4.0+ binaries, warns when -a / --lxdb_auth_id / --sync_id are missing on sync-family calls
lakexpress_execute_command — Run the command
migratorxpress_info — Read-only advisory: action="capabilities" | "workflow" | "version"
migratorxpress_validate_auth_file — Validate the JSON auth file (only file-I/O advisory tool kept separate)
migratorxpress_preview_command — Build the migrate command. Accepts the new project tag (v0.6.30+); warns on migration_db_type="postgres" against pre-0.6.32 binaries
migratorxpress_execute_command — Run the migration
arpe_get_status — Status of all four CLIs (installed / command-builder-only)
arpe_quick_start — Detect the right tool from a plain-English use case and return a workflow guide
arpe_release_notes — Return release-notes chunks for any product (product="fastbcp" | "fasttransfer" | "lakexpress" | "migratorxpress", optional version)
search_docs — BM25 full-text search over arpe.io docs sites and blog
The command-building, execution, and discovery tools return structured content
(outputSchema + structuredContent) alongside the human-readable markdown, so
MCP clients can chain calls programmatically instead of parsing prose:
*_preview_* → the built command (argv), command_string, masked command_display, explanation, and version warnings. The exact command can be handed straight to the matching *_execute_* tool.
*_execute_* → success, return_code, stdout, stderr, and parsed diagnostics.
search_docs → ranked results records; arpe_get_status → per-product status; arpe_release_notes → release-notes chunks.
Each payload carries a status field (ok / error) so success and error responses are both machine-checkable.
Conversation starters surfaced by clients that support MCP prompts (Claude Desktop, Cursor, etc.):
export-table, transfer-data, lakehouse-pipeline, migrate-database, troubleshoot.
Static capability matrices served as MCP resources so clients can prefetch them without a tool call:
arpeio://capabilities/fastbcp-formats, fasttransfer-combinations, lakexpress-capabilities, migratorxpress-capabilities.
evaluations/arpeio_eval.xml holds 10 read-only, verifiable questions used to check
that an LLM can drive the server to correct answers (tool selection, parallelism
recommendations, capability lookups, version gating). A guard test re-derives every
answer from the capability registries so the answer key stays honest:
python -m pytest tests/test_evaluations.py -qMIT
Show the status of all four Arpe.io tools (FastBCP, FastTransfer, LakeXpress, MigratorXpress). All tools work in command-builder mode by default (no binary needed). If a binary is installed, execution is also available. Does not require database connectivity or any parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tools | No | Per-product status records. |
| status | Yes | 'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed. |
| total_tools | No | Number of registered MCP tools. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by explaining the command-builder vs binary mode and the lack of database requirements. Annotations already indicate it's read-only and idempotent, so the description complements them well.
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 with two sentences that convey all necessary information without any redundancy or fluff.
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 has no parameters, has an output schema, and annotations cover safety, the description is complete. It explains the tool's scope (four tools), mode of operation, and lack of dependencies.
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 are no parameters, and the description explicitly states that no parameters are required, which is appropriate given the empty input schema. Schema coverage is 100%, so no additional parameter info is needed.
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 that the tool shows the status of four specific Arpe.io tools (FastBCP, FastTransfer, LakeXpress, MigratorXpress). It includes additional context about command-builder vs binary mode, making the purpose unambiguous and distinguishing it from sibling tools.
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 that no database connectivity or parameters are needed, implying it can be used without prerequisites. While it does not explicitly compare with alternatives, the purpose is clear and sufficient for a simple status check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Determine which Arpe.io tool to use and get a step-by-step workflow guide. Call this when the user's intent is unclear or they are new to arpe.io tools. Accepts a plain English use case description and returns the recommended tool, required parameters, and the sequence of tool calls to make. Does not execute anything.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | Override auto-detection and show the workflow for a specific product. If omitted, the tool selects based on use_case. | |
| use_case | Yes | Plain English description of what the user wants to do (e.g., 'export a large Oracle table to S3 as Parquet', 'migrate SQL Server schema to PostgreSQL'). Used to auto-detect the right tool. |
| Name | Required | Description |
|---|---|---|
| steps | No | Recommended sequence of tool calls. |
| status | Yes | 'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed. |
| warning | No | Cross-tool caveat (e.g. internal use of FastBCP/FastTransfer). |
| selected_product | No | Recommended product, 'all', or null if undetermined. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds 'Does not execute anything,' confirming no side effects. This fully aligns with annotations and provides complete behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the purpose, then usage guidance, then input/output summary. Every sentence adds value without redundancy. Highly 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?
For a guidance tool with 2 parameters and an output schema, the description fully covers when to use, what it accepts, what it returns, and its non-destructive nature. No gaps.
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% with descriptions for both parameters. The description adds context about the 'product' parameter allowing override of auto-detection, but otherwise does not significantly add meaning beyond the schema. Base score of 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 tool's purpose: to determine which Arpe.io tool to use and provide a step-by-step workflow guide. It explicitly distinguishes itself from sibling execution tools by stating 'Does not execute anything.'
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 explicitly advises calling this tool 'when the user's intent is unclear or they are new to arpe.io tools.' It provides clear usage context but does not explicitly mention when not to use it or list alternatives, though the sibling list implies the alternative is to directly use specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return release-notes chunks for any Arpe.io product. Pass product to select which tool and optionally version to filter to a specific release. Read-only; queries the local docs cache.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Which product's release notes to retrieve. | |
| version | No | Optional version string (e.g. '0.31', '0.4'). Omit for the newest indexed version. |
| Name | Required | Description |
|---|---|---|
| count | No | Number of release-notes chunks returned. |
| chunks | No | |
| status | Yes | 'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed. |
| product | No | |
| version | No | Requested version, or null for the newest indexed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that it queries the local docs cache, providing additional context beyond annotations. 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 concise with two sentences, no filler, and the purpose is front-loaded. Every sentence adds value.
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 simplicity (2 parameters, output schema exists), the description provides sufficient context: what it does, parameters, and read-only nature. No gaps identified.
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 restates the parameter purposes in a narrative form but does not add new semantic meaning beyond the schema descriptions.
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 tool returns release-notes chunks for any Arpe.io product, with product selection and optional version filtering. It distinguishes from sibling tools like product-specific info tools and search_docs by specifying release notes specifically.
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 read-only and local cache querying, but does not explicitly state when to use this tool over alternatives like search_docs or product-specific info tools. It lacks guidance on when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a FastBCP export command that was previously built by fastbcp_preview_export. Requires confirmation=true as a safety gate. Does NOT build the command — the command string must come from a prior fastbcp_preview_export call. Will fail if the FastBCP binary is not installed.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The full command string from fastbcp_preview_export output (with actual passwords, not the masked version). | |
| confirmation | Yes | Safety gate — must be true to execute. Confirms the user has reviewed the command from fastbcp_preview_export. |
| Name | Required | Description |
|---|---|---|
| status | Yes | 'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed. |
| stderr | No | |
| stdout | No | |
| log_dir | No | |
| success | No | True when the command exited 0. |
| diagnostics | No | Parsed hints when the command failed. |
| return_code | No | Process exit code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description reinforces this with 'safety gate' and 'requires confirmation=true'. It adds context about command source and binary requirement. 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?
Three sentences, each containing essential information. Front-loaded with purpose. No redundant or irrelevant 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 full schema coverage and existence of an output schema (not shown), the description provides sufficient context for usage. It covers prerequisites, safety, and failure conditions. However, it could mention output details or error scenarios.
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% with descriptions for both parameters. The description adds value by specifying the command must be from fastbcp_preview_export and include actual passwords, which goes 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?
The description clearly states it executes a FastBCP export command built by fastbcp_preview_export, using the verb 'execute' and specifying the resource. It distinguishes from the sibling tool fastbcp_preview_export by noting it does not build the command.
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?
It explicitly states the prerequisite (command from fastbcp_preview_export) and the safety gate (confirmation=true). It also notes failure case (binary not installed). However, it does not mention when not to use this tool or provide explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about FastBCP capabilities, parallelism recommendations, workflow guidance, or binary version. Use action to select what information you need. Read-only, does not require database connectivity.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | What information to retrieve. formats: list supported source databases, output formats, and storage targets. parallelism: get a recommended parallelism method for a specific table (requires source_type, has_numeric_key, table_size_estimate). workflow: get a step-by-step export guide with database-specific tips (requires source_type, output_format). version: report installed binary version and capabilities. | |
| source_type | No | Source database type (required for action=parallelism and action=workflow) | |
| output_format | No | Desired output format (required for action=workflow) | |
| storage_target | No | Storage target (optional, for action=workflow, default: local) | local |
| has_numeric_key | No | Whether the table has a numeric key column (required for action=parallelism) | |
| has_identity_column | No | Whether the table has an identity/auto-increment column (optional, for action=parallelism) | |
| table_size_estimate | No | Estimated table size (required for action=parallelism). small: <100K rows. medium: 100K-10M. large: >10M. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond them: it requires no database connectivity, lowering the cost/risk of calling it as a discovery step. It does not describe output shape, but the annotation bar is already met.
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 tight sentences, front-loaded with what is retrieved, followed by the read-only/no-connectivity note. The 'Use `action` to select' clause is mildly redundant with the schema, but overall there is little waste.
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 read-only info tool with full schema coverage and complete annotations, the description is nearly sufficient. It could be more complete by noting that action-specific required params must be supplied together, but nothing critical for correct invocation is missing, and no output schema means return values need no explanation.
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% and each parameter documents its per-action requirement (e.g. source_type required for parallelism/workflow), so the schema does the heavy lifting. The description only restates that `action` selects the information, adding no syntax or dependency detail 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 FastBCP capability/workflow/parallelism/version info, with the action enum naming the four information categories. It is clear what the tool does, but it never distinguishes itself from sibling info tools like fasttransfer_info, lakexpress_info, or migratorxpress_info that occupy the same 'get info' niche.
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?
Tells the agent to use `action` to select the needed information and notes it is read-only with no DB connectivity, implying a safe discovery call. However, it gives no when-to-use guidance versus the many sibling *_info and *_preview tools, nor any hint about sequencing with fastbcp_execute_export.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build and preview a FastBCP export command WITHOUT executing it. Shows the exact CLI command with passwords masked. If no parallelism method is specified, one is auto-suggested based on the source database type. Does NOT test connectivity or execute the export. After reviewing, pass the command to fastbcp_execute_export.
| Name | Required | Description | Default |
|---|---|---|---|
| output | Yes | ||
| source | Yes | ||
| options | No | ||
| os_type | No | Target operating system for command formatting | linux |
| config_file | No | Path to a YAML configuration file (--config parameter, requires FastBCP 0.30+) |
| Name | Required | Description |
|---|---|---|
| tips | No | Suggested next tool calls to resolve errors. |
| errors | No | Field-level validation errors (status='error'). |
| status | Yes | 'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed. |
| command | No | Full CLI argv with real credentials, ready to hand to the execute tool. |
| warnings | No | Version-compatibility warnings. |
| explanation | No | Human-readable summary of what the command does. |
| preview_only | No | True when no binary is configured (execution unavailable). |
| command_string | No | The argv joined into one command string (real credentials). |
| command_display | No | The command with passwords masked, safe to show the user. |
| auto_parallelism | No | Parallelism method auto-suggested when none was given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real value beyond them: passwords are masked in the emitted command, a parallelism method is auto-suggested when unspecified, and connectivity is not tested. It stops short of describing pagination/output shape, but that is minor given the output schema exists.
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?
Four tight sentences, all front-loaded: what it does, what it emits, what it defaults, and where to go next. No filler.
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 an output schema present the description needn't explain return values, and it correctly focuses on the preview-to-execute workflow. Only slight gap is no mention of validation failures or what happens when required source/output fields are missing.
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?
Top-level schema coverage is only 40%, but the nested property descriptions (format, method, degree, merge) are unusually thorough and carry most parameter meaning. The description adds one behavioral rule (method auto-suggestion) but no syntax or format guidance, so it does not compensate for the low coverage figure.
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 ('Build and preview a FastBCP export command') and immediately scopes it as non-executing, which cleanly separates it from fastbcp_execute_export in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('After reviewing, pass the command to fastbcp_execute_export') and when-not ('Does NOT test connectivity or execute the export'), naming the downstream alternative directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a FastTransfer command that was previously built by fasttransfer_preview_transfer. Requires confirmation=true as a safety gate. Does NOT build the command — the command string must come from a prior fasttransfer_preview_transfer call. Will fail if the FastTransfer binary is not installed.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The full command string from fasttransfer_preview_transfer output (the unmasked version with actual passwords). Do not modify this string. | |
| confirmation | Yes | Safety gate. Must be explicitly set to true to execute. false or omitted = execution is blocked. Always confirm with the user before setting to true. |
| Name | Required | Description |
|---|---|---|
| status | Yes | 'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed. |
| stderr | No | |
| stdout | No | |
| log_dir | No | |
| success | No | True when the command exited 0. |
| diagnostics | No | Parsed hints when the command failed. |
| return_code | No | Process exit code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that the command contains actual passwords, requires a safety gate, and will fail if binary is not installed, providing valuable behavioral context beyond annotations.
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?
Four concise sentences, each providing essential information. Front-loaded with the main action and prerequisite, no unnecessary words.
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 full schema description, output schema availability, and annotations, the description covers workflow dependency, safety valve, and failure condition. It is sufficiently complete for correct usage.
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% with good descriptions. The description adds extra guidance: 'Do not modify this string' for command and 'Always confirm with the user' for confirmation, enhancing meaning 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?
The description clearly states the verb 'Execute' and the resource 'a FastTransfer command previously built by fasttransfer_preview_transfer'. It distinguishes itself from the sibling fasttransfer_preview_transfer which builds the command.
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 specifies prerequisites (must have a prior preview call, binary installed) and a safety gate (confirmation=true). It does not explicitly mention when not to use or compare with other siblings, but the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about FastTransfer capabilities, parallelism recommendations, workflow guidance, or binary version. Use action to select what information you need. Read-only, does not require database connectivity.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | What information to retrieve. combinations: list supported source-to-target database pairs. parallelism: get a recommended parallelism method for a specific table (requires source_type, has_numeric_key, table_size_estimate). workflow: get a step-by-step transfer guide with database-specific tips (requires source_type, target_type). version: report installed binary version and capabilities. | |
| source_type | No | Source database type (required for action=parallelism and action=workflow) | |
| target_type | No | Target database type (required for action=workflow) | |
| has_numeric_key | No | Whether the table has a numeric key column (required for action=parallelism) | |
| has_identity_column | No | Whether the table has an identity/auto-increment column (optional, for action=parallelism) | |
| table_size_estimate | No | Estimated table size (required for action=parallelism). small: <100K rows. medium: 100K-10M. large: >10M. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Read-only, does not require database connectivity,' adding context beyond annotations (readOnlyHint, idempotentHint). It reinforces the non-destructive, idempotent nature and clarifies no DB connection is needed, which is valuable for agent decision-making.
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 only two sentences, both front-loaded with key information. It covers purpose, usage hint, and behavioral trait without any fluff. Every sentence 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 the tool's simplicity, abundant schema descriptions, and annotations, the description is mostly complete. It doesn't explain return format or error behavior, but for a read-only info tool with strong schema support, this is acceptable. Could optionally mention that some actions require additional parameters (already in schema).
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?
All parameters have descriptions in the schema (100% coverage), so the description adds no new semantics. The description mentions using 'action' but doesn't elaborate on other parameters. Baseline score of 3 is appropriate given the high 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 tool retrieves information about FastTransfer capabilities, parallelism, workflow, or version. The verb 'Get information' and the specific resource 'FastTransfer' make the purpose explicit, distinguishing it from sibling info tools like fastbcp_info or lakexpress_info.
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 advises to use the 'action' parameter to select the needed information and notes the tool is read-only and doesn't require database connectivity. While it provides clear context, it doesn't explicitly contrast with alternative tools for transfers or other operations, but the purpose is clear enough for an agent to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build and preview a FastTransfer database-to-database transfer command WITHOUT executing it. Shows the exact CLI command with passwords masked. If no parallelism method is specified, one is auto-suggested based on the source database type. Does not test connectivity or execute the transfer. After reviewing, pass the command to fasttransfer_execute_transfer.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| target | Yes | ||
| options | No | ||
| os_type | No | Operating system where FastTransfer will run. Affects command quoting and path separators. linux: uses single quotes and forward slashes. windows: uses double quotes and backslashes. | linux |
| Name | Required | Description |
|---|---|---|
| tips | No | Suggested next tool calls to resolve errors. |
| errors | No | Field-level validation errors (status='error'). |
| status | Yes | 'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed. |
| command | No | Full CLI argv with real credentials, ready to hand to the execute tool. |
| warnings | No | Version-compatibility warnings. |
| explanation | No | Human-readable summary of what the command does. |
| preview_only | No | True when no binary is configured (execution unavailable). |
| command_string | No | The argv joined into one command string (real credentials). |
| command_display | No | The command with passwords masked, safe to show the user. |
| auto_parallelism | No | Parallelism method auto-suggested when none was given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by specifying that passwords are masked, parallelism is auto-suggested if not specified, and that connectivity is not tested. This aligns with the readOnlyHint and destructiveHint annotations, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two paragraphs) and front-loaded with the key action. Every sentence contributes relevant information, though the structure could be improved with bullet points for 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 high complexity (multiple nested parameters) and the existence of an output schema, the description covers the main behavioral aspects: what it does, what it doesn't do, and how to follow up. It could include more detail on the output format, but overall it is adequately 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?
The schema description coverage is only 25% (only os_type has a description at top level). The tool description does not compensate by explaining the source, target, or options parameters, leaving the agent to rely on the incomplete schema info. The description adds no parameter meaning beyond what is in 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?
The description clearly states the verb 'Build and preview' and the resource 'FastTransfer database-to-database transfer command', and explicitly distinguishes it from the sibling 'fasttransfer_execute_transfer' by stating it does not execute the command.
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 this tool (before execution) and when not to use it (does not test connectivity or execute), and directs the agent to pass the result to 'fasttransfer_execute_transfer'. It lacks explicit mention of when to use alternatives like 'fasttransfer_info', but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a LakeXpress command that was previously built by lakexpress_preview_command. Requires confirmation=true as a safety gate. The command string must come from a prior lakexpress_preview_command call. Will fail if the LakeXpress binary is not installed.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The exact command string from a prior lakexpress_preview_command call. Must be passed as-is without modification. | |
| confirmation | Yes | Safety gate: must be true to execute. Set to true only after the user has reviewed the previewed command. |
| Name | Required | Description |
|---|---|---|
| status | Yes | 'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed. |
| stderr | No | |
| stdout | No | |
| log_dir | No | |
| success | No | True when the command exited 0. |
| diagnostics | No | Parsed hints when the command failed. |
| return_code | No | Process exit code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description adds value by disclosing that the binary must be installed and that confirmation is required. 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?
Three sentences, each necessary and front-loaded. No redundant information.
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 output schema exists, annotations provide safety info, and parameters are well-documented, the description covers prerequisites, safety, and execution constraints fully. No gaps.
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% and description adds critical context: the command must be passed as-is from preview, and confirmation must be true after user review. This goes beyond schema definitions.
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 uses the specific verb 'Execute' and names the resource 'LakeXpress command that was previously built by lakexpress_preview_command', clearly differentiating from sibling tools like lakexpress_info or lakexpress_preview_command.
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?
It explicitly states when to use (after preview), the prerequisite (command must come from lakexpress_preview_command), and the safety gate (confirmation must be true). This provides clear guidance and excludes misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about LakeXpress capabilities, workflow guidance, or binary version. Use action to select what information you need. Read-only, does not require database connectivity.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | What information to retrieve. capabilities: list supported source databases, log databases, storage backends, and publish targets. workflow: get the recommended command sequence for a specific use case (requires source_type, destination). version: report installed binary version and capabilities. | |
| destination | No | Storage backend (required for action=workflow) | |
| source_type | No | Source database type (required for action=workflow) | |
| publish_target | No | Optional publish target (for action=workflow) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds 'Read-only, does not require database connectivity' beyond the annotations that already declare readOnlyHint and idempotentHint. 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?
Two sentences with no wasted words. Essential information is front-loaded: purpose, action usage, read-only nature.
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 output schema, description could mention output format, but parameter descriptions already specify what each action returns. Covers key aspects adequately for this simple tool.
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 detailed enum explanations. The description adds only minimal guidance ('Use `action` to select what information you need'), not significantly beyond 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?
Description clearly states 'Get information about LakeXpress capabilities, workflow guidance, or binary version' using a specific verb and resource. It differentiates from sibling info tools (e.g., arpe_get_status, fastbcp_info) by specifying LakeXpress scope.
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?
Description provides context by naming LakeXpress as the subject and instructs to use the 'action' parameter. While it implies alternative tools for other products, it does not explicitly exclude them or contrast with search_docs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build and preview a LakeXpress CLI command WITHOUT executing it. Call this after lakexpress_info with action='workflow' to build each command in the recommended sequence. Shows the exact command that will be run. Does NOT execute the command or validate connections. After reviewing, pass the command to lakexpress_execute_command.
| Name | Required | Description | Default |
|---|---|---|---|
| run | No | Run a multi-step pipeline from a YAML config file. | |
| sync | No | Run a full sync (export + publish). Exports data and publishes if configured. | |
| status | No | Show sync run status and history. | |
| cleanup | No | Clean up old or failed sync runs. | |
| command | Yes | The LakeXpress command to run. logdb_init/lxdb_init: initialize databases. config_create: set up sync configuration. sync/sync_export/sync_publish: execute pipeline steps. run: full pipeline execution. status: check pipeline status. cleanup: remove completed data. | |
| os_type | No | Target operating system for command formatting | linux |
| lxdb_drop | No | Drop the log database schema (0.3.0+ replacement for logdb_drop). WARNING: permanently deletes all sync history. | |
| lxdb_init | No | Initialize the log database schema (0.3.0+ replacement for logdb_init). | |
| logdb_drop | No | Drop the log database schema. WARNING: permanently deletes all sync history and configuration. | |
| logdb_init | No | Initialize the log database schema. Creates required tables for sync management. | |
| lxdb_locks | No | Show currently locked tables in the log database (0.3.0+ replacement for logdb_locks). | |
| config_list | No | List all sync configurations. | |
| logdb_locks | No | Show currently locked tables in the log database. | |
| sync_export | No | Run export-only sync (no publish). Exports data to local or cloud storage. | |
| sync_publish | No | Run publish-only sync. Publishes previously exported data to the configured target. | |
| config_create | No | Create a new sync configuration. Requires source DB credentials and either output_dir (local) or target_storage_id (cloud). Add publish_target for data lake publishing. | |
| config_delete | No | Delete a sync configuration. | |
| lxdb_truncate | No | Clear all data from the log database while keeping the schema (0.3.0+ replacement for logdb_truncate). | |
| logdb_truncate | No | Clear all data from the log database while keeping the schema. | |
| lxdb_release_locks | No | Release stale or stuck table locks (0.3.0+ replacement for logdb_release_locks). | |
| logdb_release_locks | No | Release stale or stuck table locks in the log database. |
| Name | Required | Description |
|---|---|---|
| tips | No | Suggested next tool calls to resolve errors. |
| errors | No | Field-level validation errors (status='error'). |
| status | Yes | 'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed. |
| command | No | Full CLI argv, ready to hand to the execute tool. |
| warnings | No | Version-compatibility warnings. |
| explanation | No | Human-readable summary of what the command does. |
| command_type | No | Which LakeXpress sub-command was built. |
| preview_only | No | True when no binary is configured (execution unavailable). |
| command_string | No | The argv joined into one command string. |
| command_display | No | The command formatted for display, safe to show the user. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the no-side-effect nature (read-only, idempotent) matching annotations. It adds transparency by noting it does not execute or validate connections, beyond what annotations declare.
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 concise (4 sentences) and front-loaded with the main purpose. Every sentence is informative and 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 the complexity (21 parameters, nested objects, many sub-commands), the description provides clear usage flow. The output schema exists, so return values are documented elsewhere. Minor gap: no explicit mention of output format beyond 'shows the exact command', but the schema covers it.
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 baseline is 3. The description does not add parameter-level explanations, but the schema already provides thorough descriptions for all properties.
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 tool builds and previews a LakeXpress CLI command without executing it. It explicitly distinguishes itself from the sibling tool lakexpress_execute_command and provides a specific use case: call after lakexpress_info with action='workflow'.
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 explicit when-to-use guidance: after lakexpress_info, before lakexpress_execute_command. It also states what it does not do (execute, validate connections), helping the agent decide when to use this preview tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a MigratorXpress command that was previously built by migratorxpress_preview_command. Requires confirmation=true as a safety gate. The command string must come from a prior migratorxpress_preview_command call. Will fail if the MigratorXpress binary is not installed.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The full MigratorXpress command string copied from the migratorxpress_preview_command output (space-separated arguments). | |
| confirmation | Yes | Safety gate: must be set to true to allow execution. Confirms the user has reviewed the previewed command. |
| Name | Required | Description |
|---|---|---|
| status | Yes | 'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed. |
| stderr | No | |
| stdout | No | |
| log_dir | No | |
| success | No | True when the command exited 0. |
| diagnostics | No | Parsed hints when the command failed. |
| return_code | No | Process exit code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and non-idempotent; description adds safety gate requirement and failure condition (binary not installed), enhancing understanding beyond annotations. No contradiction.
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?
Three sentences, each serving a distinct purpose: execution, safety constraint, and prerequisite. No redundancy or fluff.
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?
Covers essential context: prerequisite (preview command), safety gate (confirmation), and failure condition (binary). Has output schema, so return details not needed. Complete for execution tool.
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 already covers both parameters with descriptions (100% coverage). Description adds context that command must be from migratorxpress_preview_command output and confirmation is a safety gate, adding value beyond 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?
Clearly states 'execute a MigratorXpress command' with verb and resource, and distinguishes from sibling migratorxpress_preview_command by specifying the command must come from a prior preview call.
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?
Provides explicit conditions: requires confirmation=true and command from preview. Implicitly indicates use after preview; no explicit when-not-to-use but clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about MigratorXpress capabilities, workflow guidance, or binary version. Use action to select what information you need. Read-only, does not require database connectivity.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | What information to retrieve. capabilities: list supported source/target databases, tasks, and modes. workflow: get the recommended task sequence for a migration (requires source_type, target_type). version: report installed binary version and capabilities. | |
| source_type | No | Source database platform (required for action=workflow) | |
| target_type | No | Target database platform (required for action=workflow) | |
| include_constraints | No | Include constraint copy steps in workflow (optional, for action=workflow) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description reinforces read-only and adds that no database connectivity is required, providing extra behavioral context. 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 two sentences, front-loaded with the core purpose, and every word adds value. No wasted or redundant 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 rich annotations and schema, the description is adequate for understanding the tool's role. However, it lacks information about the return format or examples, which would be helpful given the absence of an output schema.
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 description does not need to add much. It mentions 'Use action to select what information you need,' which is a high-level summary but does not add significant meaning beyond the schema's own parameter descriptions.
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 gets information about capabilities, workflow guidance, or binary version, using the action parameter. It is distinguished from sibling tools like migratorxpress_execute_command by its read-only nature, but does not explicitly differentiate from other 'info' tools for different products.
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 usage context: use action to select info, and notes it is read-only without DB connectivity. However, it does not specify when not to use it or suggest alternatives (e.g., when to use search_docs instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build and preview a MigratorXpress migration command WITHOUT executing it. Shows the exact CLI command with passwords masked. Does NOT execute the migration or validate database connectivity. After reviewing, pass the command to migratorxpress_execute_command. Set upgrade_migdb=true (0.7.0+) to build the metadata-DB upgrade command instead (needs only auth_file and migration_db_auth_id).
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Force overwrite of existing migration data | |
| n_jobs | No | Number of concurrent table transfers | |
| resume | No | Resume a previous run by RUN_ID | |
| fk_mode | No | How to handle foreign key constraints. trusted: create as trusted. untrusted: create and verify. disabled: skip FK creation. | |
| license | No | License key (will be masked in display) | |
| log_dir | No | Directory for log files | |
| os_type | No | Target operating system for command formatting | linux |
| p_query | No | Parallelism degree for profiling queries | |
| project | No | Project tag attached to this run, stored on the tracking tables for later filtering (0.6.30+) | |
| max_rows | No | Maximum row count filter -- only migrate tables with at most this many rows | |
| min_rows | No | Minimum row count filter -- only migrate tables with at least this many rows | |
| quiet_ft | No | Suppress FastTransfer console output during data transfer | |
| auth_file | Yes | Path to authentication/credentials JSON file | |
| load_mode | No | How to load data into target tables. truncate: clear target before loading. append: add to existing data. | |
| log_level | No | Logging verbosity level | |
| no_banner | No | Suppress the startup banner | |
| task_list | No | Tasks to run (e.g., ['translate', 'create', 'transfer'] for full migration, or ['diff'] for validation). Call `migratorxpress_info` with action='workflow' to get the recommended task sequence. | |
| basic_diff | No | Use basic diff mode (row counts only, no checksum) | |
| no_progress | No | Disable progress bar display | |
| without_xid | No | Disable transaction ID tracking during transfer | |
| license_file | No | Path to license key file | |
| aci_threshold | No | Row count threshold for auto-created indexes on target | |
| cci_threshold | No | Row count threshold for clustered columnstore index creation on target | |
| upgrade_migdb | No | Upgrade the migration (tracking) DB metadata in place to the run_id schema introduced in 0.7.0, then exit (0.7.0+). Only auth_file and migration_db_auth_id are needed; cannot be combined with task_list or resume. Pre-0.7.0 tracking DBs are also auto-upgraded on the first regular 0.7.0+ run. | |
| compute_nbrows | No | Compute row counts for source tables before transfer | |
| exclude_tables | No | Table exclude patterns, comma-separated. Supports wildcards | |
| fasttransfer_p | No | FastTransfer parallel degree (number of threads per table transfer) | |
| include_tables | No | Table include patterns, comma-separated. Supports wildcards | |
| source_db_name | No | Source database name to migrate from. Required before 0.7.2; deprecated and ignored from 0.7.2 (the source auth entry's database is used) | |
| target_db_name | No | Target database name to migrate to. Required before 0.7.2; optional from 0.7.2, where it defaults to the target auth entry's database and must match it | |
| ft_large_table_th | No | Row count threshold above which FastTransfer parallelism is used | |
| migration_db_mode | No | How to handle existing target database objects. preserve: keep existing objects. truncate: empty tables before loading. drop: drop and recreate objects. | |
| source_db_auth_id | No | Source database credential ID from the auth file | |
| target_db_auth_id | No | Target database credential ID from the auth file | |
| source_schema_name | No | Source schema name. If omitted, all schemas are migrated | |
| target_schema_name | No | Target schema name. Defaults to source schema name if omitted | |
| profiling_sample_pc | No | Percentage of rows to sample for data profiling (0-100) | |
| migration_db_auth_id | Yes | Migration tracking database credential ID from the auth file | |
| drop_tables_if_exists | No | Drop target tables before creating them. Before 0.7.2 any value, including 'false', is read as true: omit it instead of passing 'false' | |
| fasttransfer_dir_path | No | Path to FastTransfer binary directory for parallel data transfer | |
| min_sample_pc_profile | No | Minimum sample percentage for profiling small tables | |
| forced_int_id_prefixes | No | Column name prefixes to force integer identity mapping | |
| forced_int_id_suffixes | No | Column name suffixes to force integer identity mapping |
| Name | Required | Description |
|---|---|---|
| tips | No | Suggested next tool calls to resolve errors. |
| errors | No | Field-level validation errors (status='error'). |
| status | Yes | 'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed. |
| command | No | Full CLI argv with real credentials, ready to hand to the execute tool. |
| warnings | No | Version-compatibility warnings. |
| explanation | No | Human-readable summary of what the command does. |
| preview_only | No | True when no binary is configured (execution unavailable). |
| command_string | No | The argv joined into one command string (real credentials). |
| command_display | No | The command with the license key masked, safe to show the user. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds concrete behavior beyond them: passwords are masked in output, no execution or connectivity validation occurs, and upgrade_migdb cannot be combined with task_list or resume. These are actionable constraints an agent cannot derive from structured fields alone.
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?
Four tight sentences, front-loaded with what the tool does and immediately followed by its boundaries and the handoff to the execute tool. No filler; every clause carries routing or constraint information.
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 an output schema present, return values need not be described, and the description covers the key edge cases (masking, no execution, upgrade mode constraints). For a 43-param preview tool whose schema is fully documented, nothing an agent needs to invoke it correctly is missing.
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% across 43 parameters, so the schema already documents each parameter's meaning. The description explains the upgrade_migdb flag's reduced parameter requirement, but that detail is also present in the schema, so it adds marginal value. 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?
States a specific verb and resource: builds and previews a MigratorXpress migration command without executing it. It explicitly distinguishes itself from migratorxpress_execute_command and clarifies scope ('Does NOT execute the migration or validate database connectivity'), so an agent can tell it apart from siblings immediately.
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?
It names the alternative ('pass the command to migratorxpress_execute_command') and gives the condition that selects it (after reviewing). It also flags a special mode (upgrade_migdb=true) with its prerequisites, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate that a MigratorXpress JSON credentials file is well-formed and contains the required fields (auth_id, db_type, connection parameters). Call this before migratorxpress_preview_command to catch credential issues early. Does NOT test actual database connectivity.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute or relative path to the MigratorXpress JSON credentials file to validate. | |
| required_auth_ids | No | Optional list of auth_id values that must exist in the credentials file. Use this to verify source, target, and migration DB credentials are all present before building a command. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, so safety is clear. Description adds important context that actual connectivity is not tested, which annotations do not cover. Minor gap: no mention of return value or error 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?
Two sentences, no redundant phrases. Front-loaded with core purpose, followed by usage hint and limitation. Every sentence contributes meaning.
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 low-complexity tool with 2 parameters and no output schema, the description covers purpose, usage, and a key limitation (no connectivity test). It could improve by describing the validation result format (e.g., returns success/failure messages), but it's still clear enough 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 coverage is 100%, so each parameter is documented. The description adds value for required_auth_ids by explaining its purpose ('verify source, target, and migration DB credentials are all present'). This goes beyond the schema's 'optional list.'
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 explicitly states the tool validates a MigratorXpress JSON credentials file, specifying it checks well-formedness and required fields. It distinguishes from siblings by positioning as a pre-check before migratorxpress_preview_command.
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?
Provides clear when-to-use guidance: 'Call this before migratorxpress_preview_command to catch credential issues early.' Also clarifies what it does not do ('Does NOT test actual database connectivity'), preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search arpe.io documentation and blog for answers about CLI parameters, use cases, parallelism strategies, integrations, and best practices. Call this when unsure about a parameter value, need an example command, or want the recommended approach for a specific source/target/format combination. Searches across all product documentation (FastBCP, FastTransfer, LakeXpress, MigratorXpress) and the arpe.io blog simultaneously. Does not execute anything.
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | Maximum number of results to return (1-10). | |
| question | Yes | Search query — a question or keywords about arpe.io tools, parameters, or use cases (e.g., 'how to use Ntile parallelism', 'parquet compression options', 'Oracle to Snowflake pipeline'). |
| Name | Required | Description |
|---|---|---|
| count | No | Number of results returned. |
| query | No | The search query that was run. |
| status | Yes | 'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed. |
| results | No | Ranked documentation/blog chunks. |
| index_ready | No | False while indexes are still loading. |
| fully_loaded | No | False while some sources are still loading. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds that it searches across multiple product docs and blog simultaneously, does not execute anything, complementing annotations.
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 concise sentences plus product list, front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with rich annotations and output schema, description covers scope, usage, and safety fully.
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 already covers both parameters (100% coverage). Description reinforces but adds no new parameter details beyond context.
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?
Clearly states it searches documentation and blog, distinguishes from execution/info siblings.
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?
Explicitly says when to call: when unsure about parameter, need example, or want recommended approach.
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.3.6fastbcp_info1 field changedInput schema / properties / source_type / enumPrevious value: -[
- "clickhouse",
- "hana",
- "mssql",
- "msoledbsql",
- "mysql",
- "nzcopy",
- "nzoledb",
- "nzsql",
- "odbc",
- "oledb",
- "oraodp",
- "pgcopy",
- "pgsql",
- "teradata",
- "adbc_mssql",
- "adbc_pgsql",
- "adbc_oracle"
-]New value: +[
+ "clickhouse",
+ "hana",
+ "mssql",
+ "msoledbsql",
+ "mysql",
+ "nzcopy",
+ "nzoledb",
+ "nzsql",
+ "odbc",
+ "oledb",
+ "oraodp",
+ "pgcopy",
+ "pgsql",
+ "teradata",
+ "adbc_mssql",
+ "adbc_pgsql",
+ "adbc_oracle",
+ "adbc_netezza"
+]fastbcp_preview_export4 fields changedInput schema / properties / options / properties / method / descriptionPrevious value: -"Parallelism method. Ntile: even distribution on numeric key. DataDriven: distinct value partitions, works with any data type. Physloc: SQL Server physical location (no key needed). Ctid: PostgreSQL physical tuple ID (no key needed). Rowid: Oracle physical ROWID (no key needed). RangeId: numeric min/max range. Random: modulo-based approximate distribution. Timepartition: partition by time column (FastBCP 0.30+). NZDataSlice: Netezza native slicing. None: single-threaded. Call `fastbcp_info` with action='parallelism' if unsure."New value: +"Parallelism method. Ntile: even distribution on numeric key. DataDriven: distinct value partitions, works with any data type. Physloc: SQL Server physical location (no key needed). Ctid: PostgreSQL physical tuple ID (no key needed). Rowid: Oracle physical ROWID (no key needed). RangeId: numeric min/max range. Random: modulo-based approximate distribution. Timepartition: partition by time column (FastBCP 0.30+). NZDataSlice: Netezza native slicing. DBPartition: one chunk per native table partition, for SQL Server, PostgreSQL, Oracle, MySQL and Teradata; needs schema and table, no key (FastBCP 1.3+). None: single-threaded. Call `fastbcp_info` with action='parallelism' if unsure."Input schema / properties / options / properties / method / enumPrevious value: -[
- "Ctid",
- "DataDriven",
- "Ntile",
- "NZDataSlice",
- "None",
- "Physloc",
- "Random",
- "RangeId",
- "Rowid",
- "Timepartition"
-]New value: +[
+ "Ctid",
+ "DataDriven",
+ "Ntile",
+ "NZDataSlice",
+ "None",
+ "Physloc",
+ "Random",
+ "RangeId",
+ "Rowid",
+ "Timepartition",
+ "DBPartition"
+]Input schema / properties / source / properties / type / descriptionPrevious value: -"Source database connection type (e.g., 'pgsql' for PostgreSQL, 'mssql' for SQL Server, 'oraodp' for Oracle, 'mysql' for MySQL). ADBC types 'adbc_mssql' (1.0+), 'adbc_pgsql' (1.1+) and 'adbc_oracle' (1.2+) read the same databases through the Arpe ADBC drivers and write parquet output only."New value: +"Source database connection type (e.g., 'pgsql' for PostgreSQL, 'mssql' for SQL Server, 'oraodp' for Oracle, 'mysql' for MySQL). ADBC types 'adbc_mssql' (1.0+), 'adbc_pgsql' (1.1+), 'adbc_oracle' (1.2+) and 'adbc_netezza' (1.3+) read the same databases through the Arpe ADBC drivers and write parquet output only."Input schema / properties / source / properties / type / enumPrevious value: -[
- "clickhouse",
- "hana",
- "mssql",
- "msoledbsql",
- "mysql",
- "nzcopy",
- "nzoledb",
- "nzsql",
- "odbc",
- "oledb",
- "oraodp",
- "pgcopy",
- "pgsql",
- "teradata",
- "adbc_mssql",
- "adbc_pgsql",
- "adbc_oracle"
-]New value: +[
+ "clickhouse",
+ "hana",
+ "mssql",
+ "msoledbsql",
+ "mysql",
+ "nzcopy",
+ "nzoledb",
+ "nzsql",
+ "odbc",
+ "oledb",
+ "oraodp",
+ "pgcopy",
+ "pgsql",
+ "teradata",
+ "adbc_mssql",
+ "adbc_pgsql",
+ "adbc_oracle",
+ "adbc_netezza"
+]migratorxpress_preview_command3 fields changedInput schema / properties / drop_tables_if_exists / descriptionPrevious value: -"Drop target tables before creating them"New value: +"Drop target tables before creating them. Before 0.7.2 any value, including 'false', is read as true: omit it instead of passing 'false'"Input schema / properties / source_db_name / descriptionPrevious value: -"Source database name to migrate from"New value: +"Source database name to migrate from. Required before 0.7.2; deprecated and ignored from 0.7.2 (the source auth entry's database is used)"Input schema / properties / target_db_name / descriptionPrevious value: -"Target database name to migrate to"New value: +"Target database name to migrate to. Required before 0.7.2; optional from 0.7.2, where it defaults to the target auth entry's database and must match it"v0.3.5fastbcp_info1 field changedInput schema / properties / source_type / enumPrevious value: -[
- "clickhouse",
- "hana",
- "mssql",
- "msoledbsql",
- "mysql",
- "nzcopy",
- "nzoledb",
- "nzsql",
- "odbc",
- "oledb",
- "oraodp",
- "pgcopy",
- "pgsql",
- "teradata"
-]New value: +[
+ "clickhouse",
+ "hana",
+ "mssql",
+ "msoledbsql",
+ "mysql",
+ "nzcopy",
+ "nzoledb",
+ "nzsql",
+ "odbc",
+ "oledb",
+ "oraodp",
+ "pgcopy",
+ "pgsql",
+ "teradata",
+ "adbc_mssql",
+ "adbc_pgsql",
+ "adbc_oracle"
+]fastbcp_preview_export5 fields changedInput schema / properties / options / properties / log_level / enumPrevious value: -[
- "Information",
- "Debug"
-]New value: +[
+ "Information",
+ "Debug",
+ "Verbose"
+]Input schema / properties / output / properties / bool_format / enumPrevious value: -[
- "TrueFalse",
- "OneZero",
- "YesNo"
-]New value: +[
+ "automatic",
+ "true/false",
+ "1/0",
+ "t/f"
+]Input schema / properties / output / properties / parquet_compression / enumPrevious value: -[
- "None",
- "Snappy",
- "Gzip",
- "Lz4",
- "Lzo",
- "Zstd"
-]New value: +[
+ "None",
+ "Snappy",
+ "Brotli",
+ "Gzip",
+ "Lz4",
+ "Lz4Raw",
+ "Zstd"
+]Input schema / properties / source / properties / type / descriptionPrevious value: -"Source database connection type (e.g., 'pgsql' for PostgreSQL, 'mssql' for SQL Server, 'oraodp' for Oracle, 'mysql' for MySQL)"New value: +"Source database connection type (e.g., 'pgsql' for PostgreSQL, 'mssql' for SQL Server, 'oraodp' for Oracle, 'mysql' for MySQL). ADBC types 'adbc_mssql' (1.0+), 'adbc_pgsql' (1.1+) and 'adbc_oracle' (1.2+) read the same databases through the Arpe ADBC drivers and write parquet output only."Input schema / properties / source / properties / type / enumPrevious value: -[
- "clickhouse",
- "hana",
- "mssql",
- "msoledbsql",
- "mysql",
- "nzcopy",
- "nzoledb",
- "nzsql",
- "odbc",
- "oledb",
- "oraodp",
- "pgcopy",
- "pgsql",
- "teradata"
-]New value: +[
+ "clickhouse",
+ "hana",
+ "mssql",
+ "msoledbsql",
+ "mysql",
+ "nzcopy",
+ "nzoledb",
+ "nzsql",
+ "odbc",
+ "oledb",
+ "oraodp",
+ "pgcopy",
+ "pgsql",
+ "teradata",
+ "adbc_mssql",
+ "adbc_pgsql",
+ "adbc_oracle"
+]migratorxpress_preview_command3 fields changedInput schema / properties / projectAdded value: +{
+ "description": "Project tag attached to this run, stored on the tracking tables for later filtering (0.6.30+)",
+ "pattern": "^[A-Za-z0-9_-]{1,64}$",
+ "type": "string"
+}Input schema / properties / upgrade_migdbAdded value: +{
+ "default": false,
+ "description": "Upgrade the migration (tracking) DB metadata in place to the run_id schema introduced in 0.7.0, then exit (0.7.0+). Only auth_file and migration_db_auth_id are needed; cannot be combined with task_list or resume. Pre-0.7.0 tracking DBs are also auto-upgraded on the first regular 0.7.0+ run.",
+ "type": "boolean"
+}Input schema / requiredPrevious value: -[
- "auth_file",
- "source_db_auth_id",
- "source_db_name",
- "target_db_auth_id",
- "target_db_name",
- "migration_db_auth_id"
-]New value: +[
+ "auth_file",
+ "migration_db_auth_id"
+]v0.3.2arpe_get_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "status": {
+ "description": "'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.",
+ "enum": [
+ "ok",
+ "error"
+ ],
+ "type": "string"
+ },
+ "tools": {
+ "description": "Per-product status records.",
+ "items": {
+ "properties": {
+ "binary_path": {
+ "type": "string"
+ },
+ "mode": {
+ "description": "'command_builder' or 'full'.",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total_tools": {
+ "description": "Number of registered MCP tools.",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}arpe_quick_start1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "selected_product": {
+ "description": "Recommended product, 'all', or null if undetermined.",
+ "type": "string"
+ },
+ "status": {
+ "description": "'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.",
+ "enum": [
+ "ok",
+ "error"
+ ],
+ "type": "string"
+ },
+ "steps": {
+ "description": "Recommended sequence of tool calls.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "warning": {
+ "description": "Cross-tool caveat (e.g. internal use of FastBCP/FastTransfer).",
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}arpe_release_notes1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "chunks": {
+ "items": {
+ "properties": {
+ "text": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "count": {
+ "description": "Number of release-notes chunks returned.",
+ "type": "integer"
+ },
+ "product": {
+ "type": "string"
+ },
+ "status": {
+ "description": "'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.",
+ "enum": [
+ "ok",
+ "error"
+ ],
+ "type": "string"
+ },
+ "version": {
+ "description": "Requested version, or null for the newest indexed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}fastbcp_execute_export1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "diagnostics": {
+ "description": "Parsed hints when the command failed.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "log_dir": {
+ "type": "string"
+ },
+ "return_code": {
+ "description": "Process exit code.",
+ "type": "integer"
+ },
+ "status": {
+ "description": "'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.",
+ "enum": [
+ "ok",
+ "error"
+ ],
+ "type": "string"
+ },
+ "stderr": {
+ "type": "string"
+ },
+ "stdout": {
+ "type": "string"
+ },
+ "success": {
+ "description": "True when the command exited 0.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}fastbcp_preview_export6 fields changedInput schema / properties / options / properties / batch_sizeRemoved value: -{
- "description": "Batch size for export operations",
- "type": "integer"
-}Input schema / properties / options / properties / load_modeRemoved value: -{
- "default": "Append",
- "description": "How to handle existing output. Append: add to existing files. Truncate: overwrite existing output before writing.",
- "enum": [
- "Append",
- "Truncate"
- ],
- "type": "string"
-}Input schema / properties / options / properties / map_methodRemoved value: -{
- "default": "Position",
- "description": "Column mapping method",
- "enum": [
- "Position",
- "Name"
- ],
- "type": "string"
-}Input schema / properties / options / properties / method / descriptionPrevious value: -"Parallelism method. Ntile: even distribution on numeric key. DataDriven: distinct value partitions, works with any data type. Physloc: SQL Server physical location (no key needed). Ctid: PostgreSQL physical tuple ID (no key needed). Rowid: Oracle physical ROWID (no key needed). RangeId: numeric min/max range. Random: modulo-based approximate distribution. Timepartition: partition by time column (FastBCP 0.30+). NZDataSlice: Netezza native slicing. None: single-threaded. Call `fastbcp_suggest_parallelism` if unsure."New value: +"Parallelism method. Ntile: even distribution on numeric key. DataDriven: distinct value partitions, works with any data type. Physloc: SQL Server physical location (no key needed). Ctid: PostgreSQL physical tuple ID (no key needed). Rowid: Oracle physical ROWID (no key needed). RangeId: numeric min/max range. Random: modulo-based approximate distribution. Timepartition: partition by time column (FastBCP 0.30+). NZDataSlice: Netezza native slicing. None: single-threaded. Call `fastbcp_info` with action='parallelism' if unsure."Input schema / properties / output / properties / storage_targetRemoved value: -{
- "default": "local",
- "description": "Where to write output files. local: local filesystem. s3/s3compatible: Amazon S3 or compatible. azure_blob/azure_datalake: Azure storage. fabric_onelake: Microsoft Fabric. gcs: Google Cloud Storage. Cloud targets require a cloud_profile.",
- "enum": [
- "local",
- "s3",
- "s3compatible",
- "azure_blob",
- "azure_datalake",
- "fabric_onelake",
- "gcs"
- ],
- "type": "string"
-}Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "auto_parallelism": {
+ "description": "Parallelism method auto-suggested when none was given.",
+ "type": "string"
+ },
+ "command": {
+ "description": "Full CLI argv with real credentials, ready to hand to the execute tool.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "command_display": {
+ "description": "The command with passwords masked, safe to show the user.",
+ "type": "string"
+ },
+ "command_string": {
+ "description": "The argv joined into one command string (real credentials).",
+ "type": "string"
+ },
+ "errors": {
+ "description": "Field-level validation errors (status='error').",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "explanation": {
+ "description": "Human-readable summary of what the command does.",
+ "type": "string"
+ },
+ "preview_only": {
+ "description": "True when no binary is configured (execution unavailable).",
+ "type": "boolean"
+ },
+ "status": {
+ "description": "'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.",
+ "enum": [
+ "ok",
+ "error"
+ ],
+ "type": "string"
+ },
+ "tips": {
+ "description": "Suggested next tool calls to resolve errors.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "warnings": {
+ "description": "Version-compatibility warnings.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}fasttransfer_execute_transfer1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "diagnostics": {
+ "description": "Parsed hints when the command failed.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "log_dir": {
+ "type": "string"
+ },
+ "return_code": {
+ "description": "Process exit code.",
+ "type": "integer"
+ },
+ "status": {
+ "description": "'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.",
+ "enum": [
+ "ok",
+ "error"
+ ],
+ "type": "string"
+ },
+ "stderr": {
+ "type": "string"
+ },
+ "stdout": {
+ "type": "string"
+ },
+ "success": {
+ "description": "True when the command exited 0.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}fasttransfer_preview_transfer3 fields changedInput schema / properties / options / properties / method / descriptionPrevious value: -"Parallelism method. Ntile: even distribution on numeric key. DataDriven: distinct value partitions, works with any data type. PhysLoc/Physloc: SQL Server physical location (no key needed). Ctid: PostgreSQL physical tuple ID (no key needed). Rowid: Oracle physical ROWID (no key needed). RangeId: numeric min/max range. Random: modulo-based approximate distribution. NZDataSlice: Netezza native slicing. None: single-threaded. Call `fasttransfer_suggest_parallelism` if unsure."New value: +"Parallelism method. Ntile: even distribution on numeric key. DataDriven: distinct value partitions, works with any data type. PhysLoc/Physloc: SQL Server physical location (no key needed). Ctid: PostgreSQL physical tuple ID (no key needed). Rowid: Oracle physical ROWID (no key needed). RangeId: numeric min/max range. Random: modulo-based approximate distribution. NZDataSlice: Netezza native slicing. None: single-threaded. Call `fasttransfer_info` with action='parallelism' if unsure."Input schema / properties / target / properties / type / descriptionPrevious value: -"Target database connection type (e.g., 'pgsql' for PostgreSQL, 'mssql' for SQL Server, 'oraodp' for Oracle, 'mysql' for MySQL). Use fasttransfer_list_combinations to see valid pairs."New value: +"Target database connection type (e.g., 'pgsql' for PostgreSQL, 'mssql' for SQL Server, 'oraodp' for Oracle, 'mysql' for MySQL). Use `fasttransfer_info` with action='combinations' to see valid pairs."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "auto_parallelism": {
+ "description": "Parallelism method auto-suggested when none was given.",
+ "type": "string"
+ },
+ "command": {
+ "description": "Full CLI argv with real credentials, ready to hand to the execute tool.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "command_display": {
+ "description": "The command with passwords masked, safe to show the user.",
+ "type": "string"
+ },
+ "command_string": {
+ "description": "The argv joined into one command string (real credentials).",
+ "type": "string"
+ },
+ "errors": {
+ "description": "Field-level validation errors (status='error').",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "explanation": {
+ "description": "Human-readable summary of what the command does.",
+ "type": "string"
+ },
+ "preview_only": {
+ "description": "True when no binary is configured (execution unavailable).",
+ "type": "boolean"
+ },
+ "status": {
+ "description": "'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.",
+ "enum": [
+ "ok",
+ "error"
+ ],
+ "type": "string"
+ },
+ "tips": {
+ "description": "Suggested next tool calls to resolve errors.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "warnings": {
+ "description": "Version-compatibility warnings.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}lakexpress_execute_command1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "diagnostics": {
+ "description": "Parsed hints when the command failed.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "log_dir": {
+ "type": "string"
+ },
+ "return_code": {
+ "description": "Process exit code.",
+ "type": "integer"
+ },
+ "status": {
+ "description": "'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.",
+ "enum": [
+ "ok",
+ "error"
+ ],
+ "type": "string"
+ },
+ "stderr": {
+ "type": "string"
+ },
+ "stdout": {
+ "type": "string"
+ },
+ "success": {
+ "description": "True when the command exited 0.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}lakexpress_preview_command3 fields changedInput schema / properties / config_create / properties / error_action / descriptionPrevious value: -"Action on table export error: fail (stop), continue (skip and continue), skip"New value: +"Action on table export error: fail (stop on first error) or continue (log errors and continue)"Input schema / properties / config_create / properties / error_action / enumPrevious value: -[
- "fail",
- "continue",
- "skip"
-]New value: +[
+ "fail",
+ "continue"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "command": {
+ "description": "Full CLI argv, ready to hand to the execute tool.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "command_display": {
+ "description": "The command formatted for display, safe to show the user.",
+ "type": "string"
+ },
+ "command_string": {
+ "description": "The argv joined into one command string.",
+ "type": "string"
+ },
+ "command_type": {
+ "description": "Which LakeXpress sub-command was built.",
+ "type": "string"
+ },
+ "errors": {
+ "description": "Field-level validation errors (status='error').",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "explanation": {
+ "description": "Human-readable summary of what the command does.",
+ "type": "string"
+ },
+ "preview_only": {
+ "description": "True when no binary is configured (execution unavailable).",
+ "type": "boolean"
+ },
+ "status": {
+ "description": "'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.",
+ "enum": [
+ "ok",
+ "error"
+ ],
+ "type": "string"
+ },
+ "tips": {
+ "description": "Suggested next tool calls to resolve errors.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "warnings": {
+ "description": "Version-compatibility warnings.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}migratorxpress_execute_command1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "diagnostics": {
+ "description": "Parsed hints when the command failed.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "log_dir": {
+ "type": "string"
+ },
+ "return_code": {
+ "description": "Process exit code.",
+ "type": "integer"
+ },
+ "status": {
+ "description": "'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.",
+ "enum": [
+ "ok",
+ "error"
+ ],
+ "type": "string"
+ },
+ "stderr": {
+ "type": "string"
+ },
+ "stdout": {
+ "type": "string"
+ },
+ "success": {
+ "description": "True when the command exited 0.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}migratorxpress_preview_command2 fields changedInput schema / properties / task_list / descriptionPrevious value: -"Tasks to run (e.g., ['translate', 'create', 'transfer'] for full migration, or ['diff'] for validation). Call migratorxpress_suggest_workflow to get the recommended task sequence."New value: +"Tasks to run (e.g., ['translate', 'create', 'transfer'] for full migration, or ['diff'] for validation). Call `migratorxpress_info` with action='workflow' to get the recommended task sequence."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "command": {
+ "description": "Full CLI argv with real credentials, ready to hand to the execute tool.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "command_display": {
+ "description": "The command with the license key masked, safe to show the user.",
+ "type": "string"
+ },
+ "command_string": {
+ "description": "The argv joined into one command string (real credentials).",
+ "type": "string"
+ },
+ "errors": {
+ "description": "Field-level validation errors (status='error').",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "explanation": {
+ "description": "Human-readable summary of what the command does.",
+ "type": "string"
+ },
+ "preview_only": {
+ "description": "True when no binary is configured (execution unavailable).",
+ "type": "boolean"
+ },
+ "status": {
+ "description": "'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.",
+ "enum": [
+ "ok",
+ "error"
+ ],
+ "type": "string"
+ },
+ "tips": {
+ "description": "Suggested next tool calls to resolve errors.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "warnings": {
+ "description": "Version-compatibility warnings.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}search_docs1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "count": {
+ "description": "Number of results returned.",
+ "type": "integer"
+ },
+ "fully_loaded": {
+ "description": "False while some sources are still loading.",
+ "type": "boolean"
+ },
+ "index_ready": {
+ "description": "False while indexes are still loading.",
+ "type": "boolean"
+ },
+ "query": {
+ "description": "The search query that was run.",
+ "type": "string"
+ },
+ "results": {
+ "description": "Ranked documentation/blog chunks.",
+ "items": {
+ "properties": {
+ "source": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "description": "'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.",
+ "enum": [
+ "ok",
+ "error"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}v0.3.1arpe_get_statusarpe_quick_startarpe_release_notesfastbcp_execute_exportfastbcp_infofastbcp_preview_exportfasttransfer_execute_transferfasttransfer_infofasttransfer_preview_transferlakexpress_execute_commandlakexpress_infolakexpress_preview_commandmigratorxpress_execute_commandmigratorxpress_infomigratorxpress_preview_commandmigratorxpress_validate_auth_filesearch_docsScored across 17 tools
Product prefixes (fastbcp_, fasttransfer_, lakexpress_, migratorxpress_) clearly scope each tool, and preview/execute pairs are well distinguished by the confirmation gate. The four near-identical *_info tools and the overlap between search_docs, the per-product info actions, and arpe_release_notes create some informational overlap, but the prefixes resolve most confusion.
The core verb_noun pattern (preview_export, execute_export, preview_command, execute_command) is consistent and readable. However the noun choices diverge by product (export/command/transfer) for the same conceptual action, and the shared tools mix conventions: arpe_get_status, arpe_quick_start, arpe_release_notes are prefixed while search_docs is not.
17 tools is reasonable for a set covering four distinct CLI products plus shared utility tools, and each tool has an evident purpose. It is on the heavier side and the replicated *_info tools add some redundancy, but nothing feels like pure filler.
Each product gets a build→confirm→execute lifecycle plus info, which covers the core command-building workflow end to end. The main gap is asymmetric: migratorxpress_validate_auth_file has no counterpart for FastBCP/FastTransfer/LakeXpress, which also consume credentials, leaving agents without early validation for three of the four products.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.