Skip to main content
Glama
EyevinnOSC

Eyevinn Open Source Cloud MCP Server

by EyevinnOSC

osc_upload_file

Upload a file to an Eyevinn Open Source Cloud Storage Minio instance by specifying the instance name, bucket, object key, and file path.

Instructions

Upload a file to Eyevinn Open Source Cloud Storage (OSC) Minio instance

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName of the minio instance
bucketYesName of the bucket
objectKeyYesObject key for the uploaded file
fileYesFile to upload

Implementation Reference

  • The 'uploadFile' helper function that resolves the Minio instance and delegates to uploadFileToMinioBucket. This is the main handler logic called by the switch case for osc_upload_file.
    export async function uploadFile(
      name: string,
      bucket: string,
      objectKey: string,
      file: string,
      context: Context
    ) {
      const instance = await getMinioInstance(context, name);
      if (!instance) {
        throw new Error(`Minio instance with name ${name} not found`);
      }
      return await uploadFileToMinioBucket(
        instance.endpoint,
        instance.accessKeyId,
        instance.secretAccessKey,
        bucket,
        objectKey,
        file
      );
    }
  • The actual upload implementation: creates a Minio client from endpoint/credentials, determines MIME type from file extension, and uploads via minioClient.fPutObject.
    export async function uploadFileToMinioBucket(
      endpoint: string,
      accessKeyId: string,
      secretAccessKey: string,
      bucket: string,
      objectKey: string,
      filePath: string
    ) {
      const minioClient = new Minio.Client({
        endPoint: new URL(endpoint).hostname,
        accessKey: accessKeyId,
        secretKey: secretAccessKey
      });
    
      // Get mime type based on file extension
      const contentType = mime.lookup(filePath) || 'application/octet-stream';
    
      const metaData = {
        'Content-Type': contentType
      };
    
      const uploadedObject = await minioClient.fPutObject(
        bucket,
        objectKey,
        filePath,
        metaData
      );
      return uploadedObject;
    }
  • Zod schema defining the inputs for osc_upload_file: name (minio instance name, regex validated), bucket, objectKey, and file path.
    export const UploadFileSchema = z.object({
      name: z
        .string()
        .regex(/^[a-z0-9]+$/)
        .describe('Name of the minio instance'),
      bucket: z.string().describe('Name of the bucket'),
      objectKey: z.string().describe('Object key for the uploaded file'),
      file: z.string().describe('File to upload')
    });
  • src/tools/osc.ts:19-26 (registration)
    Registration of the tool 'osc_upload_file' with its name, description, and inputSchema in the listOscTools function.
    export function listOscTools() {
      return [
        {
          name: 'osc_upload_file',
          description:
            'Upload a file to Eyevinn Open Source Cloud Storage (OSC) Minio instance',
          inputSchema: zodToJsonSchema(UploadFileSchema)
        },
  • src/index.ts:103-117 (registration)
    Top-level registration: listOscTools() provides the tool list via ListToolsRequestSchema, and handleOscToolRequest routes 'osc_' prefixed tool calls to the handler.
    private setupToolHandlers(): void {
      this.server.setRequestHandler(ListToolsRequestSchema, async () => ({
        tools: listOscTools()
      }));
    
      this.server.setRequestHandler(CallToolRequestSchema, async (request) => {
        if (request.params.name.startsWith('osc_')) {
          return await handleOscToolRequest(request, this.context);
        } else {
          throw new McpError(
            ErrorCode.InvalidRequest,
            `Unknown tool: ${request.params.name}`
          );
        }
      });
Behavior2/5

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

With no annotations, the description carries full burden but only states 'upload'. It does not disclose behavioral traits like whether the upload overwrites existing objects, required permissions, file size limits, or asynchronicity.

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, succinct sentence that immediately conveys the action and target. Every word is necessary; no redundancy.

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?

Given the complexity (4 required parameters, no output schema, no annotations), the description is too minimal. It fails to explain return values, success/failure signals, or error handling, leaving an AI agent undersupported.

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?

Schema coverage is 100% with each parameter described. The description adds no additional meaning beyond the schema's descriptions, so it meets the baseline but does not exceed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Upload a file') and the target resource ('Eyevinn Open Source Cloud Storage (OSC) Minio instance'). It is specific and distinguishable from sibling tools (bucket/list operations), though it does not explicitly differentiate.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., listing files or creating buckets). There is no mention of prerequisites (e.g., bucket must exist) or exclusions.

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/EyevinnOSC/mcp-server'

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