Skip to main content
Glama
ctslone

CData Arc MCP Server

by ctslone

create_connector

Create an Arc connector with a unique ID, connector type, and flow role (trigger, terminal, transform, or none) to set up data integration across workspaces.

Instructions

Create a new Arc connector. Requires connectorId, connectorType, and action. The action property defines the connector's role in flows. If workspaceId is not specified, connector is created in the default workspace.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesConnector's role in flows (required). Trigger: starts flow (pulls/receives data). Terminal: ends flow (sends/stores data). Transform: processes data in middle of flow. None: for dual-role connectors like File that adapt to their position.
logLevelNoLog level: None, Error, Warning, Info, Debug, or Trace
maxFilesNoMaximum files to process per worker assignment
maxWorkersNoMaximum workers from pool for this connector
connectorIdYesUnique identifier for the new connector (required)
logMessagesNoWhether to keep message copies in Logs directory
workspaceIdNoThe workspace ID (defaults to 'default' if not specified)
connectorTypeYesConnector type (required). Always use the latest version of a connector when one exists — versioned types use the suffix 'v2', 'v3', etc. (e.g., use 'RESTv2' not 'REST', 'AS4v2' not 'AS4'). Other common types: 'AS2', 'FTP', 'SFTP', 'File', 'X12', 'MySQL'.
automationSendNoWhether to automatically process files in the Send folder
receiveIntervalNoInterval for automatic file receiving. Use a plain number (in minutes) for simple schedules, e.g., '15' for every 15 minutes, '60' for every hour. For complex schedules use a 5-part cron expression, e.g., '0 2 * * *' for daily at 2 AM.
saveToSentFolderNoWhether to keep copies in Sent folder
sentFolderSchemeNoSent folder structure: Daily, Weekly, Monthly, or Yearly
automationReceiveNoWhether to automatically receive files at specified interval
logSubFolderSchemeNoLog folder structure: Daily, Weekly, Monthly, or Yearly
automationMaxAttemptsNoMaximum retry attempts (0 for unlimited)
automationRetryIntervalNoTime to wait after error before retry, in minutes
Behavior2/5

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It mentions the required fields and default workspace, but fails to describe side effects (e.g., creating resources), idempotency, error handling, or whether special permissions are needed. For a create operation, this leaves important behavioral aspects undisclosed.

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?

The description is appropriately short and front-loaded with the core purpose. Each sentence serves a purpose: stating the action, listing required inputs, explaining a key property, and clarifying a default. It could be slightly more structured, but it is concise and readable.

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

Completeness3/5

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

Given the tool has 16 parameters and no output schema, the description covers the essential creation context (required params, role of action, default workspace) without delving into optional parameter selection or return values. The 100% schema coverage compensates for most parameter-specific detail, but the lack of output/error information and connector-type-specific guidance makes it only minimally complete.

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%, so the description does not need to repeat parameter details. It adds minimal semantic value by explicitly naming the three required parameters and the default workspace behavior, both of which are already present in schema descriptions. The description thus provides no significant extra meaning beyond the schema.

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?

The description clearly states the tool's action ('Create') and resource ('a new Arc connector'), making it easily distinguishable from sibling tools like update_connector, delete_connector, and get_connector. The scope is explicit and unambiguous.

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 provides some usage guidance by listing required parameters and explaining the default workspace behavior when workspaceId is omitted. However, it does not explicitly contrast with alternatives (e.g., update_connector for modifying existing connectors) or state scenarios where this tool should not be used.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ctslone/AdminAPI_MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server