Skip to main content
Glama

w3_ls

List files and directories in IPFS storage using JSON format. Ideal for managing data and storage spaces within the MCP-IPFS server environment.

Instructions

Tool for w3_ls operation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jsonNoFormat output as newline delimited JSON (default: true).

Implementation Reference

  • The handler function that implements the core logic for the w3_ls tool. It validates input arguments using the schema, runs the corresponding w3 CLI command, parses NDJSON output if in JSON mode, and formats the response for MCP.
    const handleW3Ls: ToolHandler = async (args) => {
      const parsed = Schemas.W3LsArgsSchema.safeParse(args);
      if (!parsed.success)
        throw new Error(`Invalid arguments for w3_ls: ${parsed.error.message}`);
      const { json } = parsed.data;
      const command = json ? "ls --json" : "ls";
      const { stdout } = await runW3Command(command);
      if (json) {
        const uploads = parseNdJson(stdout);
        return {
          content: [{ type: "text", text: JSON.stringify({ uploads }) }],
        };
      } else {
        return {
          content: [
            { type: "text", text: JSON.stringify({ output: stdout.trim() }) },
          ],
        };
      }
    };
  • Zod schema for validating the input arguments to the w3_ls tool, featuring an optional 'json' boolean flag defaulting to true.
    export const W3LsArgsSchema = z.object({
      json: z
        .boolean()
        .optional()
        .default(true)
        .describe("Format output as newline delimited JSON (default: true)."),
    });
  • Maps the tool name 'w3_ls' to its handler function in the exported toolHandlers object, which is used by the MCP server to dispatch tool calls.
    w3_ls: handleW3Ls,
Behavior1/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it offers no information about what the tool does (e.g., whether it lists files, spaces, or other resources), what permissions are required, whether it's read-only or destructive, or what the output looks like. This lack of behavioral context makes it inadequate for a tool with no annotation coverage.

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 a single, under-specified sentence that fails to convey meaningful information. While concise, it's not appropriately sized for the tool's complexity—it lacks essential details about the tool's purpose and behavior. This isn't efficient brevity but rather insufficient content.

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

Completeness1/5

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

Given the lack of annotations, no output schema, and a vague description, the description is incomplete. It doesn't explain what the tool lists, how to interpret results, or any behavioral traits, leaving significant gaps for an agent to understand and use the tool effectively. This is inadequate for a tool in a context with many sibling listing operations.

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 has 1 parameter with 100% description coverage, documenting that 'json' controls output formatting as newline delimited JSON. The description adds no parameter information beyond this, but since schema coverage is high, the baseline score is 3. The description doesn't compensate for any gaps, but none exist in the schema.

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

Purpose2/5

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

The description 'Tool for w3_ls operation' is a tautology that merely restates the tool name without explaining what the operation does. It doesn't specify what resource is being listed or what 'w3' refers to, making the purpose vague. While sibling tools like 'w3_space_ls' and 'w3_delegation_ls' suggest this might list something, the description fails to clarify what specifically.

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

Usage Guidelines1/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. It doesn't mention any context, prerequisites, or exclusions, and doesn't differentiate it from sibling tools like 'w3_space_ls' or 'w3_delegation_ls' that also perform listing operations. This leaves the agent with no usage direction.

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

Related 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/alexbakers/mcp-ipfs'

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