Skip to main content
Glama
Sign In
arpeio-mcp

arpeio-mcp

Official
by arpe-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

arpe_get_status

Read-onlyIdempotent

Check whether FastBCP, FastTransfer, LakeXpress, and MigratorXpress are available for command-builder mode or binary execution; no parameters or database connection required.

Instructions

Show the status of the four Arpe.io CLI 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "arpe_get_status"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
toolsNoPer-product status records.
statusYes'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.
total_toolsNoNumber of registered MCP tools.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.2
    • 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"
+}
  2. First observedv0.3.1

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuine operational context: no binary is required by default, execution is only available when a binary is installed, and no database connectivity is needed. It doesn't describe the returned status fields, but an output schema exists to cover that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core purpose, then the mode caveat, then the preflight guarantee. Every sentence carries information, though the final clause slightly restates what the empty schema already implies.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, no parameters, and full annotation coverage, the description only needs to establish what the tool reports and what it requires. It does both, and adds the binary-vs-command-builder nuance that an agent needs to interpret the results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so the baseline is 4. The description reinforces the empty schema by stating it does not require any parameters, removing any ambiguity about whether auth or connection details are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Show the status') and names the exact resource: the four Arpe.io CLI tools, listed by name. This implicitly differentiates it from the per-tool siblings (fastbcp_info, lakexpress_info, migratorxpress_info) by being the aggregate status view, though it never says so explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the command-builder vs. binary-installed execution modes, which is real context for deciding whether preview/execute siblings are usable. But it never states when to call this tool rather than arpe_quick_start or the per-tool *_info tools, leaving the selection to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools