Skip to main content
Glama
ai-yliu

Filesystem MCP Server

by ai-yliu

read_multiple_files

Read multiple files at once to access their contents simultaneously, saving time compared to reading files individually.

Instructions

Read multiple files simultaneously

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathsYesArray of file paths to read

Implementation Reference

  • The handler function for the 'read_multiple_files' tool. Extracts paths from input, loops through each validating access and reading content or capturing errors, then returns a JSON-formatted array of results with path, content, or error per file.
    case 'read_multiple_files': {
      const { paths } = request.params.arguments as { paths: string[] };
      
      const results: { path: string; content?: string; error?: string }[] = [];
      
      for (const filePath of paths) {
        try {
          validatePath(filePath);
          const content = await fs.readFile(filePath, 'utf8');
          results.push({ path: filePath, content });
        } catch (error) {
          results.push({ 
            path: filePath, 
            error: error instanceof Error ? error.message : String(error) 
          });
        }
      }
      
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(results, null, 2),
          },
        ],
      };
    }
  • src/index.ts:109-125 (registration)
    Registration of the 'read_multiple_files' tool in the ListTools response, specifying name, description, and input schema for an object with required 'paths' array of strings.
    {
      name: 'read_multiple_files',
      description: 'Read multiple files simultaneously',
      inputSchema: {
        type: 'object',
        properties: {
          paths: {
            type: 'array',
            items: {
              type: 'string',
            },
            description: 'Array of file paths to read',
          },
        },
        required: ['paths'],
      },
    },
  • Input schema definition for the 'read_multiple_files' tool, requiring an object with a 'paths' property that is an array of strings.
    inputSchema: {
      type: 'object',
      properties: {
        paths: {
          type: 'array',
          items: {
            type: 'string',
          },
          description: 'Array of file paths to read',
        },
      },
      required: ['paths'],
    },
Behavior2/5

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

No annotations are provided, so the description carries full burden. While 'read' implies a non-destructive operation, it doesn't disclose important behavioral traits: whether it requires specific permissions, how it handles missing/inaccessible files, whether it returns partial results on errors, or any rate limits. The description adds minimal value beyond the basic action.

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 extremely concise at just 4 words, front-loading the core functionality with zero wasted words. Every word earns its place by specifying the action, target, and concurrency aspect.

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?

For a tool that reads multiple files with no annotations and no output schema, the description is insufficient. It doesn't explain what format the results come in (array of contents? object mapping paths to content?), how errors are handled, or any constraints on the number/size of files. Given the complexity of batch operations, more context is needed.

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 description coverage is 100% (the 'paths' parameter is fully documented in the schema), so the baseline is 3. The description doesn't add any parameter-specific information beyond what the schema already provides about the array of file paths.

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 'Read multiple files simultaneously' clearly states the verb (read) and resource (multiple files), and specifies the concurrency aspect (simultaneously). However, it doesn't explicitly distinguish this tool from its sibling 'read_file' which presumably reads single files, missing full sibling differentiation.

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?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'read_file' (single file) and 'search_files' (search-based reading), there's no indication of when batch reading is preferred over sequential single-file reads or search operations.

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/ai-yliu/filesystem-mcp-server'

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