Skip to main content
Glama
LaubPlusCo

WebDAV MCP Server

by LaubPlusCo

webdav_update_remote_file

Modify existing files on a remote WebDAV server by replacing their content with new data. Specify the file path and updated content to apply changes.

Instructions

Update an existing file on a remote WebDAV server with new content

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
contentYes

Implementation Reference

  • Main tool handler function: checks if the remote file exists, then writes new content using WebDAVService
    async ({ path, content }) => {
      try {
        // Check if file exists
        const exists = await webdavService.exists(path);
        if (!exists) {
          return {
            content: [{
              type: 'text',
              text: `Error: File does not exist at ${path}`
            }],
            isError: true
          };
        }
    
        await webdavService.writeFile(path, content);
        
        return {
          content: [{
            type: 'text',
            text: `File updated successfully at ${path}`
          }]
        };
      } catch (error) {
        return {
          content: [{
            type: 'text',
            text: `Error updating file: ${(error as Error).message}`
          }],
          isError: true
        };
      }
    }
  • Input schema validation using Zod for path and content parameters
      path: z.string().min(1, 'Path must not be empty'),
      content: z.string()
    },
  • Registers the webdav_update_remote_file tool with the MCP server
    server.tool(
      'webdav_update_remote_file',
      'Update an existing file on a remote WebDAV server with new content',
      {
        path: z.string().min(1, 'Path must not be empty'),
        content: z.string()
      },
      async ({ path, content }) => {
        try {
          // Check if file exists
          const exists = await webdavService.exists(path);
          if (!exists) {
            return {
              content: [{
                type: 'text',
                text: `Error: File does not exist at ${path}`
              }],
              isError: true
            };
          }
    
          await webdavService.writeFile(path, content);
          
          return {
            content: [{
              type: 'text',
              text: `File updated successfully at ${path}`
            }]
          };
        } catch (error) {
          return {
            content: [{
              type: 'text',
              text: `Error updating file: ${(error as Error).message}`
            }],
            isError: true
          };
        }
      }
    );
  • Core helper method implementing WebDAV file update via putFileContents
    async writeFile(path: string, content: string | Buffer): Promise<void> {
      const fullPath = this.getFullPath(path);
      const contentLength = typeof content === 'string' ? content.length : content.length;
      logger.debug(`Writing file: ${fullPath}`, { contentLength });
      
      try {
        // putFileContents in v5.x returns a boolean indicating success
        const result = await this.client.putFileContents(fullPath, content);
        
        // Check result based on type
        if (typeof result === 'boolean' && !result) {
          throw new Error("Failed to write file: server returned failure status");
        } else if (this.isResponseData(result) && 
                   result.status !== undefined && 
                   result.status !== 201 && 
                   result.status !== 204) {
          throw new Error(`Failed to write file: server returned status ${result.status}`);
        }
        
        logger.debug(`Successfully wrote file: ${fullPath}`);
      } catch (error) {
        logger.error(`Error writing to file ${fullPath}:`, error);
        throw new Error(`Failed to write file: ${(error as Error).message}`);
      }
    }
  • Helper method to check if the remote path exists before attempting update
    async exists(path: string): Promise<boolean> {
      const fullPath = this.getFullPath(path);
      logger.debug(`Checking if exists: ${fullPath}`);
      
      try {
        const result = await this.client.exists(fullPath);
        
        // Handle both boolean and object responses
        let exists = false;
        
        if (typeof result === 'boolean') {
          exists = result;
        } else if (result && typeof result === 'object') {
          // Use type guard for better type safety
          const responseData = result as ResponseData;
          if (responseData.status !== undefined) {
            exists = responseData.status < 400; // If status is less than 400, the resource exists
          }
        }
        
        logger.debug(`Exists check for ${fullPath}: ${exists}`);
        return exists;
      } catch (error) {
        logger.error(`Error checking existence of ${fullPath}:`, error);
        return false;
      }
    }
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool updates a file with new content, implying a write/mutation operation, but lacks critical details: required permissions (e.g., write access), whether it overwrites or merges content, error handling (e.g., if file doesn't exist), rate limits, or response format. This leaves significant gaps for safe and effective use.

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, efficient sentence that front-loads the core action ('Update an existing file') and resource ('on a remote WebDAV server with new content'). There is no wasted verbiage, making it highly concise and well-structured for quick comprehension.

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 of a file update operation with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks details on permissions, error conditions, content handling, and response expectations, which are essential for a mutation tool in a remote server context. This leaves the agent with insufficient information for reliable invocation.

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?

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'path' and 'content' implicitly but doesn't explain their semantics: what format 'path' should be (e.g., absolute/relative), what 'content' represents (e.g., text, binary encoding), or constraints (e.g., size limits). The description adds minimal value beyond the schema's structural definition.

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 ('Update') and resource ('an existing file on a remote WebDAV server with new content'), making the purpose immediately understandable. It distinguishes itself from siblings like 'webdav_create_remote_file' by specifying 'existing file' and 'update', though it doesn't explicitly contrast with other modification tools like 'webdav_move_remote_item' or 'webdav_copy_remote_item'.

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. It doesn't mention prerequisites (e.g., file must exist), exclusions (e.g., not for directories), or comparisons with siblings like 'webdav_move_remote_item' for moving files or 'webdav_create_remote_file' for new files. Usage is implied but not explicitly defined.

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

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