Skip to main content
Glama
EyevinnOSC

Eyevinn Open Source Cloud MCP Server

by EyevinnOSC

osc_list_files

Lists files in a specified bucket on an Eyevinn Open Source Cloud Storage Minio instance, using the instance name and bucket name.

Instructions

List files in a bucket on Eyevinn Open Source Cloud Storage (OSC) Minio instance

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName of the minio instance
bucketYesName of the bucket

Implementation Reference

  • The handler case that executes the 'osc_list_files' tool logic. It parses arguments via ListFilesSchema, calls the listFiles helper, and returns a formatted response with file names.
    case 'osc_list_files': {
      const args = ListFilesSchema.parse(request.params.arguments);
      const files = await listFiles(args.name, args.bucket, context);
      return {
        content: [
          {
            type: 'text',
            text: `Files in bucket '${args.bucket}' on MinIO instance '${args.name}':`
          }
        ].concat(
          files.map((file) => ({
            type: 'text',
            text: file
          }))
        )
      };
    }
  • The listFiles helper function called by the handler. It resolves the MinIO instance from context and delegates to listFilesInMinioBucket.
    export async function listFiles(
      name: string,
      bucket: string,
      context: Context
    ) {
      const instance = await getMinioInstance(context, name);
      if (!instance) {
        throw new Error(`Minio instance with name ${name} not found`);
      }
      return await listFilesInMinioBucket(
        instance.endpoint,
        instance.accessKeyId,
        instance.secretAccessKey,
        bucket
      );
    }
  • The low-level helper that connects to the MinIO instance and lists all objects in the bucket, returning their names as an array of strings.
    export async function listFilesInMinioBucket(
      endpoint: string,
      accessKeyId: string,
      secretAccessKey: string,
      bucket: string
    ): Promise<string[]> {
      const minioClient = new Minio.Client({
        endPoint: new URL(endpoint).hostname,
        accessKey: accessKeyId,
        secretKey: secretAccessKey
      });
    
      const objects = await minioClient.listObjects(bucket, '', true);
      const fileList: string[] = [];
      for await (const obj of objects) {
        fileList.push(obj.name);
      }
      return fileList;
    }
  • The Zod schema for validating input arguments of osc_list_files - requires 'name' (alphanumeric minio instance name) and 'bucket' (bucket name).
    export const ListFilesSchema = z.object({
      name: z
        .string()
        .regex(/^[a-z0-9]+$/)
        .describe('Name of the minio instance'),
      bucket: z.string().describe('Name of the bucket')
    });
    
    export type ListFilesSchema = z.infer<typeof ListFilesSchema>;
  • src/tools/osc.ts:27-32 (registration)
    The tool registration entry for 'osc_list_files' inside listOscTools(), which is used by the MCP ListTools handler.
    {
      name: 'osc_list_files',
      description:
        'List files in a bucket on Eyevinn Open Source Cloud Storage (OSC) Minio instance',
      inputSchema: zodToJsonSchema(ListFilesSchema)
    },
Behavior3/5

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

No annotations are provided, so the description carries the burden of disclosure. It states the operation is to list files, which implies a read-only behavior, but it does not mention authorization needs, rate limits, error handling, or the format of the output. The description is minimally transparent.

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, concise sentence that directly states the tool's purpose. It is front-loaded with the key action and resource, and contains no extraneous information.

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

Completeness3/5

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

The tool is simple with two parameters and no output schema. The description provides the essential purpose but lacks details on the return type (e.g., list of file names or metadata) and any specific behavior like pagination. It is adequate but not fully complete for an agent invoking the tool.

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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no additional meaning beyond the schema; it does not elaborate on constraints like the name pattern or what constitutes a valid bucket.

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 verb 'List', the resource 'files in a bucket', and the specific service (Eyevinn OSC Minio instance). It effectively distinguishes itself from sibling tools like osc_create_bucket and osc_list_buckets by specifying the action on files within a bucket.

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 description implies usage when wanting to list files in a bucket, but it does not provide explicit guidance on when to use this tool versus alternatives, or mention prerequisites (e.g., bucket must exist). No exclusions or context for selection are given.

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