Skip to main content
Glama
fbossiere

Proton Safe MCP

by fbossiere

Finalize attachment upload

finish_attachment_upload

Verifies an uploaded attachment's size and SHA-256 checksum, then issues a short-lived opaque token to complete the upload.

Instructions

Verify attachment size and SHA-256, then return a short-lived opaque token.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
upload_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior3/5

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

The description adds behavioral detail beyond annotations by mentioning verification and a short-lived token, which is useful. However, it does not disclose side effects such as whether the upload becomes immutable, whether calling this twice fails, or what happens to the upload on token expiry. With no idempotentHint and no explicit side-effect warning, important behavioral transparency is missing.

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 a single, focused sentence with no wasted words. It front-loads the core action and clearly communicates the intended result.

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

Completeness2/5

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

While an output schema exists, the description lacks essential contextual guidance: when in the upload lifecycle to call this, what the opaque token should be used for, and what prerequisites must be met. For a multi-step upload flow with six related sibling tools, this is incomplete.

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

Parameters2/5

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

The schema has 0% description coverage for parameters, so the description must compensate. It never mentions upload_id, how it is used, or why it must match the given pattern. The only parameter is left to be inferred from the tool name and context.

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 action: verify attachment size and SHA-256, then return a short-lived opaque token. This precisely identifies the finalization step and distinguishes it from sibling upload operations like begin_attachment_upload or upload_attachment_chunk.

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

Usage Guidelines2/5

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

There is no guidance on when to call this tool relative to the upload flow. It does not mention prerequisites such as 'after all chunks have been uploaded' or that it should precede prepare_draft or commit_approved_draft. The agent must infer usage from the tool name and sibling context.

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/fbossiere/proton-safe-mcp'

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