MCP服务器连Claude后，为啥只能读文件不能写？

这问题我前阵子也踩过，卡了两天最后翻源码才搞明白。MCP的filesystem服务器默认暴露的tools确实只有read相关的几个，写操作得在server初始化时通过capabilities显式声明，比如加上“write”: true，不然Claude那边收到的工具列表里压根就没有create/write这些方法，自然就报权限错。你检查一下server端注册工具时有没有把write相关的handler挂上，光在配置里写“permissions”是不够的，MCP协议的安全模型就是默认最小权限，所有能力都得主动声明。另外Claude端目前确实有沙盒限制，就算服务器声明了写权限，如果对话上下文里没有明确授权操作路径，它也可能拒绝执行，所以可以试试在系统提示词里直接说“允许修改/workspace下的文件”这种话。我最后是用自定义transport绕过的，直接改了server的tool列表才搞定，官方文档这块确实写得模糊，社区里也一堆人卡这。

这个坑我上周刚踩过，跟Claude的权限模型关系不大，问题基本都出在MCP服务器自己的能力声明上。filesystem这个参考实现默认只暴露了read相关的tools，你要在server初始化时把write、edit这些操作也加进capabilities里，而且注意别漏了resource templates的权限配置。我一开始也是只改了tools列表，结果还是被拒，后来发现Claude对资源的写操作会先走一次permission check，那个allow规则没配好就白搭。另外如果你是本地跑，可以试试在启动命令里加--dangerously-skip-permissions，但千万别在远程环境这么搞，纯属给自己挖坑。还有个更隐蔽的点，如果你用SDK的话，有些版本对write操作的参数校验特别严格，比如文件路径必须是绝对路径，相对路径会直接报错。建议先抓一下MCP的日志，看看到底是卡在协议层还是业务层，这样排查起来快很多。

MCP的filesystem默认就是只读的，得在server配置里显式加write权限，不然Claude那边永远只发读请求。

大概率是filesystem那个server默认只暴露了只读工具，你得自己改一下server的tool定义加上write才行。

我之前也卡在这个坑里过，最后发现根子不在Claude那边，而是MCP协议里server端声明的capabilities没写全。你用的filesystem服务器，默认实现里可能只暴露了read和list相关的tools，write操作要么没注册，要么注册了但权限校验默认拒绝。你可以直接抓一下MCP的初始化握手日志，看server返回的tools列表里到底有没有create/write方法，没有的话就得改服务器源码或配置文件，把对应tool显式加进去。另外有些封装好的fileserver会用环境变量或白名单来控制可写目录，如果Claude进程的工作目录和你的目标文件夹不一致，就算声明了write也会被系统权限挡下来。至于Claude默认只读沙盒这个说法，我实测下来它本身不限制MCP返回的tool权限，关键在于server端怎么实现，所以大概率是你服务器配置的问题。你试试直接在本地用MCP Inspector调一下同一个tool，如果也报权限错，那就跟Claude无关，纯粹是服务器端没放开。

我之前也卡在这过，后来发现是MCP的tool定义里只声明了read相关的capability，write权限需要在server端显式加进tools列表里，Claude这边不会自动放开的。你可以试试在resources里把目标目录的write权限也写上，光改配置不够，还得检查下运行MCP的进程有没有文件系统层面的写权限。另外如果用的是官方fileserver，我记得它默认就是只读的，得自己fork一份改代码才行。

在工具配置里把read权限换成readwrite就行，我上次也卡这，改完立马能写了。

这题我刚好踩过坑，关键确实在能力声明那块。你检查下MCP server返回的tools列表里有没有带write权限，Claude端默认对未知操作会保守处理，只放行read。另外resource的uri格式也得注意，有时候是路径没匹配上导致写操作被拦。你可以试试在server启动日志里加打印，看请求到底到没到你的写函数。

这问题我上周刚踩完坑，大概率不是Claude那边限制了写权限，而是MCP服务器端的能力声明没配全。filesystem服务器默认暴露的tools列表里，read操作是自动注册的，但write/create这类操作得在服务器初始化时显式加进capabilities里，而且还要在resources部分把目标目录的readWrite属性标出来。文档确实写得含糊，我当时是直接去翻SDK源码才发现的。另外提醒一下，就算声明了写权限，Claude的system prompt里也会对文件修改操作做二次确认，有时候它自己会拒绝执行，看起来就像权限错误。你可以先用MCP Inspector直接调工具测一下，如果能写就说明是Claude那边的行为限制，得在对话里明确要求它使用write工具。我最后是改了服务器配置里那个permission数组，把allowedOperations加上write才通的。

这问题我也踩过坑，大概率是Claude那边的客户端配置默认把MCP工具当只读沙盒用了，跟服务器声明关系不大。你试试在Claude的配置文件里给这个MCP server加上--dangerously-write-file这种参数，或者直接在权限设置里把filesystem的读写开关打开。我之前就是卡在这，文档确实写得含糊，得翻源码才找到。另外确认下你用的MCP SDK版本，新版好像改了默认权限策略。

大概率是filesystem服务器默认只暴露了read权限，你需要在tools配置里显式加上write和edit的权限声明才能写入。

这问题我上周刚踩完坑，你卡在权限上大概率不是Claude的沙盒限制，而是MCP协议里tool定义那层没放开。filesystem服务器默认暴露的read工具和write工具是分开声明的，你检查一下server端代码里有没有把write_text、edit_file这类操作注册进tool列表，光有资源定义但没在capabilities里声明可写方法，客户端那边收到的能力清单就是只读的。另外Claude Desktop端的权限弹窗有时候会默认选“允许读取但拒绝修改”，你可以在连接设置里把文件系统的write权限手动勾上，或者干脆在server初始化时把allowedDirectory指向具体项目路径，别用根目录。还有个小坑，如果用的官方SDK，记得把session的permission模式从“readonly”改成“readwrite”，这参数藏得深，文档里一笔带过。我最后是直接改了server的tool注册逻辑才通的，你试试在启动日志里看有没有输出“registered N tools”，如果数量对不上就知道缺了哪几个。

这个坑我也踩过，关键确实在能力声明那块。MCP的filesystem服务器默认只暴露了read相关的tools，写操作得自己在server配置里显式加上write和edit权限，光改资源定义没用。另外检查下你连Claude时用的OAuth scope，如果只授权了只读范围，就算服务器支持写入也会被拦。我最后是在MCP的初始化参数里手动传了allowedWriteDirectories，再把tools里的write方法打开才搞定。你试试看是不是漏了这步。

大概率是MCP配置里没显式声明write权限，Claude默认只读沙盒，去server配置里加上对应能力声明试试。

我之前也卡在这块儿过，折腾了两天才搞明白。你猜的没错，就是“能力声明”的问题，Claude的MCP实现默认只信任read操作，你要在server初始化时明确把write和edit加进capabilities列表里，而且每个resource路径下还得单独配permissions，缺一个它就给你报权限错。文档这块确实写得模糊，我最后是去翻了MCP协议的GitHub讨论区才找到答案。另外提醒一下，就算声明了写权限，Claude侧还有个安全确认机制，有时候不是真拒绝，是它在等你在对话里点头确认——我当时就被这假象迷惑了好久。你要是用官方fileserver的docker镜像，记得环境变量里把ALLOW_WRITE设成true，比改代码省事。要是还不行，试试把工作目录挂载到容器外，权限问题往往跟容器用户ID映射有关。

大概率是MCP工具定义里没把write加进permissions，你得在server端显式声明才行，默认确实只读。

我之前也卡在这块儿，折腾了两天才搞明白。你猜对了，核心就是MCP的能力声明，filesystem服务器默认暴露的tool列表里只有read和list相关的操作，write和edit压根儿没被注册进去，所以Claude界面看起来就是只能读。解决办法不是去改Claude的沙盒配置，那个是死的，你得在MCP服务器的代码里手动把write、edit这些tool加进server.setRequestHandler的注册列表，然后重新构建启动。另外有个坑是，就算你加了write，资源模板里也得定义对应的uri模式，比如file:///project/**，并且标明可写，不然权限校验那层还是会拦你。我当初就是漏了第二步，光加tool不更新资源定义，结果报错信息一模一样。建议你直接看官方fileserver的源码，里面有个read_only的flag，默认是true，改成false或者建个新实例时传参覆盖就行，比手动声明tool省事多了。要是你用的是别人封装好的包，记得查一下它的构造函数支不支持这个参数，不支持就得fork下来自己改了。

我之前也卡在这过，问题基本就是MCP的权限模型默认只开放只读，filesystem服务器虽然能列文件，但写操作需要你在server配置里显式声明allowedDirectories或者直接给write权限，Claude那边倒不是沙盒限制。你可以检查下启动MCP时传的参数，比如--read-only是不是被默认加上了，去掉之后重启一般就能写了。另外有些版本还要求在tool定义里把permissions字段补全，光靠资源定义不够，你试试在server端代码里手动加上write相关的handler，应该能绕过这个坑。

这问题我也踩过坑，关键在MCP协议里tools和resources是两套权限体系，filesystem默认只暴露了读操作。你需要在服务器代码里显式调用server.tool()注册write相关的方法，光改配置文件没用。另外Claude端设置里有个“允许执行写操作”的开关，默认确实是关的，记得去开发者模式下打开，不然就算服务器声明了也会被拦。你试下把权限模型改成permissive模式，应该就能过了。

大概率是MCP server配置里capabilities没声明write权限，Claude默认保守策略，改一下server端代码就行。