Skip to main content
Glama
arpeio-mcp

arpeio-mcp

Official
by arpe-io

search_docs

Read-onlyIdempotent

Searches Arpe.io documentation and blog to answer questions on CLI parameters, use cases, parallelism, and integrations. Use it to find example commands and recommended approaches.

Instructions

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 ADBC drivers ArpeMSSQL, ArpePGSQL, ArpeOracle, ArpeNetezza, ArpeTeradata) and the arpe.io blog simultaneously. Does not execute anything.

Input Schema

NameRequiredDescriptionDefault
top_kNoMaximum number of results to return (1-10).
questionYesSearch 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').

Output Schema

NameRequiredDescriptionDefault
countNoNumber of results returned.
queryNoThe search query that was run.
statusYes'ok' when the call succeeded; 'error' when the parameters failed validation or execution failed.
resultsNoRanked documentation/blog chunks.
index_readyNoFalse while indexes are still loading.
fully_loadedNoFalse while some sources are still loading.

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": {
      +    "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"
      +}
  2. First observedv0.3.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds real value beyond them by clarifying that retrieval spans all product docs and the blog simultaneously and that it 'does not execute anything', which heads off any confusion with the preview/execute siblings. Return shape is covered by the output schema, so no gap there.

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 sentences, each carrying distinct information: capability, trigger conditions, and scope/behavior. The long product roll-call is the only slightly heavy element, but it is load-bearing for knowing what corpus is searched.

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

Completeness4/5

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

Purpose, trigger conditions, corpus scope, and a non-execution disclaimer are all present, and annotations plus the output schema cover safety profile and return format. What remains thin is only the query-formulation guidance, which the schema already handles.

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

Parameters3/5

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

Schema coverage is 100% and both parameters are fully documented in the schema, so the description is not required to compensate. It reinforces the kind of natural-language query expected but adds no syntax, ranking, or top_k guidance beyond the schema. Baseline 3 applies.

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

Purpose5/5

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

States a specific verb (search) and resource set (arpe.io documentation and blog) plus the exact topic domain it covers (CLI parameters, parallelism, integrations, best practices). It also enumerates the covered products, which lets an agent separate it from the per-product info tools 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.

Usage Guidelines4/5

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

Gives three concrete triggers: unsure about a parameter value, need an example command, or want a recommended approach for a source/target/format combination. It does not name a specific alternative sibling (e.g., fastbcp_info) to prefer for static product facts, so routing is strong but not fully explicit.

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