trace_path: accept `callers`/`callees` as aliases for `direction`
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
调研方向
通过搜索字符串 'invalid direction' 定位 trace_path 工具的实现——那里是解析 direction 的地方；在验证之前添加 callers→inbound 和 callees→outbound 的规范化。同时找到声明 trace_path 的 direction 枚举的 JSON schema，并添加这两个别名，以便 MCP 客户端进行本地验证。完成的标准是：输入时两种拼写都被接受，而响应仍然返回 inbound/outbound；运行现有的工具参数测试以确认没有其他改动。
由索引模型根据 Issue 内容生成。
描述
trace_path: accept callers/callees as aliases for direction
Version: 0.10.8 (macOS, single static binary)
What happens
trace_path's direction takes inbound / outbound / both. Passing the word most callers
reach for first is rejected:
trace_path(function_name="safe_null_result", project="…", direction="callers", depth=1)
→ invalid direction "callers" — use "inbound" (callers), "outbound" (callees), or "both"
Why this is worth a one-line change
The error message already contains the fix. It glosses inbound as (callers) and outbound
as (callees) — the server knows exactly what the rejected word means and says so in the act of
refusing it. There is no ambiguity to resolve, no second meaning of "callers" to disambiguate
against; the mapping is already written down in the rejection.
It also costs a round trip every time, and the round trip is not free for the caller this tool is
built for: an agent burns a tool call, reads an error, and retries. That is the whole interaction
budget the README's "99% fewer tokens" is about.
The wider context is that "callers" is the more common spelling of this concept across the tools an
agent is likely to be holding at the same time. Anything wrapping this backend and exposing a
caller/callee vocabulary hits the mismatch on the boundary — I ran into it from a wrapper whose own
surface uses op: "callers", so the two names for one concept sit one call apart, and one of them
is actively refused by the other side.
Suggested fix
Accept callers → inbound and callees → outbound as input aliases, normalising to the
canonical values internally. Keep inbound/outbound as the documented names and as whatever the
response echoes — this is only about what the parser tolerates on the way in.
Both spellings in the JSON-schema enum would also let MCP clients validate either one locally,
rather than the alias being accepted by the server but rejected by client-side schema validation
first.
Not a bug
Filing this as ergonomics, not correctness. The current behaviour is well-signposted and the error
is one of the better ones in the tool — it names the valid values instead of just refusing. This is
a request to skip the round trip, not a complaint that it is wrong.
- 主要语言
- C
- 星标
- 45.8k
- 派生
- 3.8k
- 平均合并
- 3 天 4 小时
- 30 天内合并 PR
- 208
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
DeusData/codebase-memory-mcp 的其他 Issue
-
bug editor/integration
难度 2/5 1-3 小时 新手友好度 72/100
DeusData/codebase-memory-mcp#2787 · 1 条评论 ·
维护者通常 2 天内回复
-
install writes an unsupported `args` key into the Claude Code SubagentStart hook, so it never runs未关闭bug editor/integration priority/high stability/performance ux/behavior
难度 2/5 1-3 小时 新手友好度 72/100
DeusData/codebase-memory-mcp#2239 · 1 条评论 ·
维护者通常 2 天内回复
-
bug priority/high ux/behavior
难度 2/5 1-3 小时 新手友好度 72/100
DeusData/codebase-memory-mcp#2232 · 2 条评论 ·
维护者通常 2 天内回复
-
documentation editor/integration parsing/quality priority/normal
难度 2/5 1-3 小时 新手友好度 85/100
DeusData/codebase-memory-mcp#2169 ·
维护者通常 2 天内回复
-
documentation priority/normal ux/behavior
难度 2/5 1-3 小时 新手友好度 72/100
DeusData/codebase-memory-mcp#2050 ·
维护者通常 2 天内回复
查看 DeusData/codebase-memory-mcp 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 65/100
-
难度 2/5 1-3 小时 新手友好度 78/100
HexaCluster/credcheck#86 ·
-
难度 2/5 1-3 小时 新手友好度 66/100
mongodb/winkerberos#175 ·
-
bug
难度 2/5 1-3 小时 新手友好度 74/100
AOMediaCodec/SVT-AV1#3320 ·
-
difficulty: easy
难度 2/5 1-3 小时 新手友好度 64/100