Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Import a Drive / OneDrive folder into the Library

import_from_cloud

Import files from a Google Drive or OneDrive folder into your Hermoso Library using your connected account, making them available for publishing, scheduling, cloning, or product references.

Instructions

Pull the files in a Google Drive or OneDrive FOLDER into this profile's Library, so they can be used like anything rendered here — published, scheduled, cloned, used as a product photo or a reference. Hermoso downloads each file with the user's own connected account (a Drive/OneDrive file is not public, so this is the only way in) and stores a durable Hermoso url for each. Give folderId from list_drive_files / list_onedrive_files with onlyFolders — omit it for the root. GOOGLE DRIVE ONLY SHOWS WHAT THE USER HANDED OVER: our Drive scope is drive.file, so Hermoso can see the files and folders it created plus the ones the user picked with the Google picker in the app, and NEVER their whole Drive — if a folder comes back empty, that is the answer, and the user picks it in the app once to make it reachable. OneDrive has no such limit. SUBFOLDERS ARE NOT WALKED and Google-native docs (Docs/Sheets/Slides) have no file to download: both are reported back BY NAME rather than silently dropped, along with anything too large or unreadable, so you can tell the user exactly what did and did not come across.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNohow many files to bring across in this call (default 10, max 25). Anything over the limit is listed as skipped so you know what is left.
folderIdNothe folder to import, from list_drive_files / list_onedrive_files (onlyFolders:true). Omit for the root of the drive.
providerYeswhich cloud — `drive` is Google Drive, `onedrive` is Microsoft OneDrive

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.251

TDQS

A4.6/5.0
Behavior5/5

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

With annotations only covering readOnly/openWorld/idempotent/destructive flags, the description carries the real burden and does so richly: the drive.file scope limits visibility, downloads use the user's own connected account, subfolders are not walked, and Google-native docs / oversized / unreadable files are reported by name rather than dropped. This is exactly the non-obvious behavior an agent needs.

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?

Purpose is front-loaded and every paragraph addresses a distinct concern (what it does, account/scope mechanics, folderId sourcing, platform limits, reporting of skipped items). It is dense and the all-caps emphasis is heavy, but little is wasted.

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?

No output schema exists, and the description compensates by explaining what comes across and what is reported back by name, including partial-import and skip behavior. For a non-idempotent import tool this is complete enough to call correctly.

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 baseline is 3, but the description adds real meaning beyond the schema: the cross-tool provenance of folderId, the root-omission semantics, and the fact that files over `limit` are listed as skipped. That linkage and consequence go past what the schema alone states.

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?

Opens with a specific verb and resource ('Pull the files in a Google Drive or OneDrive FOLDER into this profile's Library') and immediately scopes what the imported files can then be used for. It is clearly distinguishable from siblings like list_drive_files, get_drive_file, and save_to_drive.

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?

It tells the agent how to source the required folderId (from list_drive_files / list_onedrive_files with onlyFolders) and that omitting it targets the root, plus what an empty result means. It stops short of an explicit 'use this instead of X' routing statement, but the context is clear.

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