Versium REACH

Import Cloud List Mcp Tool

import_cloud_list

Import a Google Drive or OneDrive file into REACH as a new list, using the Google Sheets or OneDrive account the user connected in REACH.

REACH doesn't browse drives: find the file with a Google Drive or OneDrive/Microsoft 365 MCP server, then pass its `url`, or `provider` and `file_id` (plus `drive_id` for OneDrive files outside the user's own drive). Next, call `setup_list` with the returned `list_id`, then `create_job`.

Supported: Google Sheets, .csv and .xlsx files on Google Drive; .csv and .xlsx files on OneDrive. Rows beyond the user's upload limit are dropped; `record_count` reflects what was kept.

Input Schema

Name	Required	Description
`url`	No	Link to a Google Sheets or Google Drive file, or a OneDrive/SharePoint file. Use instead of provider and file_id.
`file_id`	No	The Drive file ID, or the OneDrive driveItem id
`drive_id`	No	OneDrive only: the item's driveId (parentReference.driveId)
`provider`	No	Required with file_id; not used with url
`project_id`	No	Project to create the list in
`sheet_name`	No	Sheet (tab) to import from a spreadsheet or .xlsx file; required when it has more than one. Ignored for CSV.
`project_name`	No	Project to find or create when there is no project_id

Output Schema

Name	Required	Description
`source`	No
`list_id`	No
`list_url`	No
`list_name`	No
`has_header`	No	REACH's guess at whether the first row is a header
`header_row`	No
`project_id`	No
`sample_rows`	No	The first data rows, positional
`record_count`	No	Rows imported, excluding the header row when has_header is true

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare openWorld=true, non-idempotent, non-destructive, so the safety profile is covered. The description adds real behavior the annotations cannot: it requires a pre-connected Google/OneDrive account, specifies which file types are supported per provider, and discloses that rows beyond the upload limit are silently dropped with record_count reflecting only what was kept. That truncation warning is the highest-value disclosure here; only error/re-import behavior is left unstated.

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?

Front-loaded purpose, then prerequisite, then the exact call chain, then supported types, then the truncation caveat. Every sentence carries operational information and none repeats the schema or annotations.

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?

For a 7-parameter, open-world, non-idempotent import with an output schema, the description covers purpose, prerequisites, next calls, supported formats, and the data-loss caveat. What remains (e.g., empty/error file behavior, sheet_name requirement for multi-tab files) is already handled by the 100%-covered schema, so the gaps are minor.

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?

Schema coverage is 100%, so the schema already explains url, file_id, provider, and sheet_name. The description adds a condition the schema does not spell out: drive_id is needed specifically for OneDrive files outside the user's own drive, and it frames url versus provider+file_id as mutually exclusive paths. That is genuine added meaning over the field descriptions.

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 and resource ('Import a Google Drive or OneDrive file into REACH as a new list') and immediately scopes who performs it ('using the account the user connected'). The workflow sentences make it unmistakable against siblings like setup_list and create_job, which are named as the next steps rather than alternatives.

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?

Explicitly tells the agent how to get here ('REACH doesn't browse drives: find the file with a Google Drive or OneDrive/Microsoft 365 MCP server'), what to pass, and what to call afterwards ('setup_list with the returned list_id, then create_job'). This is a full usage contract, not an implied one.

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

All Versium REACH tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?