mcp-server

Set up a scheduled SFTP or S3 pull into an existing data spec

setup_scheduled_pull

End-to-end workflow for "pull files from this SFTP server / S3 bucket on a schedule" requests: reuses a matching connection if one already exists in the workspace (same hostname/username for sftp, same roleArn for aws_s3), otherwise creates one; tests it; then creates a trigger that feeds an already-analyzed data spec (see onboard_data_source) on the given frequency. Pass hostname for an sftp pull, or roleArn (+ s3Bucket, required) for an aws_s3 pull — exactly one of the two is expected. Use this instead of calling manage_connection + manage_trigger yourself for first-time setup. If the connection test fails (e.g. the sftp public key or the aws_s3 IAM role isn't set up yet on the customer's side), no trigger is created — ask the user to finish that setup and re-run this tool, which will reuse the same connection and pick up where it left off. This is for pulling a NEW file from an external source — for "run this on a schedule/after another job" where the spec queries tables already in the workspace (sourceType "tables"), use manage_trigger with type "schedule" or "spec_success" instead; there is no connection involved.

Input Schema

TableJSON Schema

Name	Required	Description
`dedupe`	No	Required — ask the user rather than assuming a value; omitting it fails the call. Whether repeat pulls should skip files already loaded into this spec, matched by file name. Has real consequences: with dedupe true, a file that reappears under the same name (e.g. re-uploaded with corrected data) will be silently skipped; with dedupe false, an unchanged file left on the server will be reloaded every run.
`roleArn`	No	aws_s3: the IAM role the customer will create/update.
`hostname`	No	sftp: SFTP server hostname to pull from.
`preRules`	No	Natural language: which files to pick up (e.g. "only *.csv under /outbound")
`s3Bucket`	No	aws_s3: bucket to poll. Required when roleArn is given.
`s3Prefix`	No	aws_s3 only. Optional key prefix; defaults to the whole bucket.
`specName`	Yes	Already-analyzed data spec to load files into (see onboard_data_source)
`username`	No	sftp only. Defaults to "sftpuser".
`frequency`	Yes	Pull schedule.
`postRules`	No	Natural language: what to do after a file loads (e.g. "rename with .done suffix")
`workspaceId`	No	Workspace to act on. Defaults to your only workspace if you have exactly one.

Output Schema

TableJSON Schema

Name	Required	Description
`dedupe`	No
`specId`	No
`enabled`	No
`message`	Yes
`s3Bucket`	No
`s3Prefix`	No
`specName`	No
`warnings`	No	aws_s3 only. Advisory notes about the created trigger, e.g. the 5000-object S3 listing cap.
`frequency`	No
`triggerId`	No	Present only once the connection test succeeded and a trigger was created.
`connectionId`	No
`testSucceeded`	No
`connectionType`	No

TDQS

A5/5.0

Behavior5/5

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

The description discloses key behaviors beyond annotations: it reuses a matching connection if one exists, otherwise creates one, tests it, and only creates a trigger if the test passes. It notes that no trigger is created on failure and that re-running picks up where it left off. It also explains consequences of dedupe true/false. This goes well beyond the minimal readOnly/destructive hints.

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

Conciseness5/5

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

The description is dense but every sentence contributes value: the workflow, parameter selection rule, alternative guidance, failure behavior, and exclusion clause. It is appropriately sized for an 11-parameter tool and front-loaded with the primary purpose.

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?

Given the tool's complexity (11 params, nested frequency object, output schema exists), the description covers the end-to-end workflow, parameter selection constraints, failure handling, and alternatives. It references onboard_data_source for the spec prerequisite. The presence of an output schema makes return-value documentation unnecessary.

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

Parameters5/5

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

The description adds crucial parameter semantics not fully captured by the schema: exactly one of hostname or roleArn must be provided, and s3Bucket is required with roleArn. It also clarifies the SFTP vs aws_s3 pull modes. Schema coverage is 100%, so this extra information elevates the score above the baseline of 3.

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 purpose with a specific verb ('Set up a scheduled SFTP or S3 pull') and identifies the resource ('into an existing data spec'). It further distinguishes itself from siblings by explicitly saying 'Use this instead of calling manage_connection + manage_trigger yourself' and referencing manage_trigger with type 'schedule' or 'spec_success' for a different use case.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance (first-time setup for scheduled external pulls), when-not-to-use guidance (schedule/spec_success on tables already in the workspace should use manage_trigger instead), and alternatives (manage_connection + manage_trigger, manage_trigger). It also explains what to do if the connection test fails (ask user to finish setup and re-run).

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

All mcp-server tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

Most tools map to distinct lifecycle phases and the descriptions explicitly separate overlapping-sounding concepts, such as list_data versus submit_query and the generic call_dpf_api from dedicated tools. The three finish_* tools are similarly worded but each is clearly tied to a specific preceding operation, so confusion should be limited.

Naming Consistency4/5

The tool names are uniformly snake_case and mostly follow a readable verb_noun pattern like delete_data_spec, create_workspace, and run_data_job. It is not a perfect 5 because broader names like manage_connection and manage_trigger, the generic call_dpf_api, and list_my_workspaces with its pronoun make the naming pattern less predictable.

Tool Count4/5

At 16 tools, the set is just slightly above the ideal range, but the tools generally earn their place by representing distinct steps or workflow boundaries. The start/finish pairs create some apparent redundancy, but that is a natural consequence of the multi-step file-upload flow.

Completeness4/5

The toolset provides solid coverage of the core data-platform lifecycle: workspaces, data specs, jobs, connections, triggers, scheduled pulls, status polling, and SQL querying. Some additional DPF capabilities are only reachable through the generic call_dpf_api rather than dedicated tools, and billing mutations are explicitly left outside the MCP surface, so coverage is strong but not absolute.

Resources

Need Help?