Sweeppea MCP

get_file_url

Read-onlyIdempotent

Generate a short-lived presigned S3 URL to download or preview a file from the user's Drive. The URL embeds the correct Content-Type and Content-Disposition headers, and the actual transfer happens directly between the client and S3 (no data transfer cost on this endpoint).

get_file_url

When to use

Parameters to validate before calling

file_token (string, required) — The file token (UUID) of the file to generate a URL for. Get via fetch_files.
mode (string, optional) — one of: preview, download — URL behavior: "preview" (inline, default) opens the file in the browser; "download" forces a file attachment download.
expires_in (number, optional) — range: 60–3600 — URL lifetime in seconds. Range: 60-3600. Default: 900 (15 minutes).

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	URL behavior: "preview" (inline, default) opens the file in the browser; "download" forces a file attachment download.
`expires_in`	No	URL lifetime in seconds. Range: 60-3600. Default: 900 (15 minutes).
`file_token`	Yes	The file token (UUID) of the file to generate a URL for. Get via fetch_files.

TDQS

A3.9/5.0

Behavior5/5

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

The description goes beyond the annotations (readOnlyHint, idempotentHint) by disclosing that the URL is short-lived, presigned, embeds Content-Type and Content-Disposition headers, and that transfer occurs directly between client and S3, avoiding data transfer costs. This is valuable behavioral context not present in the annotations.

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

Conciseness2/5

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

The description is padded with redundant sections: the opening definition is repeated verbatim under 'When to use', and the parameter details are duplicated from the schema. While structured, it is unnecessarily verbose and fails to keep each sentence purposeful.

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 read-only tool with no output schema, the description adequately covers purpose, parameters, behavior, and benefits. The absence of an explicit return-value description is acceptable since the URL is clearly implied. It loses one point for the redundant structure that does not add completeness.

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?

The input schema provides 100% coverage with detailed descriptions for all three parameters. The description restates these parameters but adds no new information beyond what annotations/schema already supply. The baseline of 3 is appropriate; the schema does the heavy lifting.

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 uses a specific verb ('generate') and names the precise resource ('short-lived presigned S3 URL') and action ('download or preview a file'). It clearly distinguishes itself from sibling tools like send_file or upload_file by focusing on URL generation for preview/download.

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 'When to use' section restates the main purpose but does not to explicitly contrast this tool with alternatives like send_file or fetch_files. There is no 'when not to use' guidance, though the benefit of 'no data transfer cost' implies a context for choosing this over direct transfer.

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

All Sweeppea MCP 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

A3.6/5.0

Disambiguation4/5

Most tools follow a clear resource+action pattern (fetch_* for lists, get_* for single items, create/update/delete for writes), making them distinguishable. A few near-overlaps exist (fetch_billing_transactions vs fetch_wallet_transactions, draw_winners vs schedule_drawing) but the descriptions clarify the boundaries.

Naming Consistency4/5

Tool names consistently use snake_case verb_noun, with fetch_ for list operations and get_ for single-item retrieval. Some verb variation (add_participant, count_participants, draw_winners, schedule_drawing) deviates from the dominant create/fetch/update/delete pattern but remains predictable and readable.

Tool Count1/5

With 83 tools, this is far beyond a well-scoped server (typically 3-15, with 25+ considered too many). Even though the platform has broad functionality, the sheer number of tools creates significant agent confusion and selection overhead.

Completeness4/5

The sweepstakes domain is thoroughly covered: lifecycle management, participants, groups, rules, drawings, winners, calendar, notes, todos, tickets, surveys, invoices, billing, files, and entry settings. A few minor gaps exist (e.g., no general participant field update, no archive action) but the surface is remarkably complete for its scope.

Resources

Need Help?