This server provides CPU performance profiling for Minecraft Bedrock Edition mods by connecting to the game's embedded Tracy profiler. It supports the full optimization workflow: probe → baseline capture → hotspot analysis → code change → re-capture → diff validation.
Probe readiness (tracy_status): Check connectivity to the native Tracy server (TCP 8086), verify bundled CLI tools (tracy-capture.exe, tracy-csvexport.exe) are present, and optionally inspect the MCDK endpoint. Run this first.
Capture function timings (tracy_native_capture): Record per-function CPU costs (self time, total time, call counts) from the live game over a configurable window (≤60 seconds), with optional mod-name filtering. Returns a top-N hotspot list and stores the full dataset for later queries.
Query function costs (tracy_get_function_costs): Retrieve self/total/call metrics from a stored capture by exact name or substring — no need to re-capture.
Diff captures (tracy_diff_captures): Compare two captures (e.g., before vs. after an optimization) to see improved, regressed, added, or removed functions with delta milliseconds and percentage change.
Frame-level health (tracy_jank_fps): Poll FPS and frame time percentiles (p1, p5, p50) via MCDK, or scrape jank/profile logs to cross-validate perceived performance improvements.
List stored captures (tracy_list_captures): View all saved sessions (id, label, totals, timestamp) to select captures for diffing or further analysis.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcdk-mcp-tracy Capture 8 seconds of profiling data filtered by 'my_mod' with label 'before'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
一个 MCP 服务器：对运行中的网易我的世界基岩版 MOD 做性能监测——采集每个函数的 CPU 耗时与帧率数据，用来定位热点、review 代码、量化验证优化效果。
三类性能监测能力：
热点定位：函数耗时排行（self / total / 调用次数），直接看到最贵的函数在哪
优化验证：前后两次采样按函数 diff，用毫秒回答"改完真的变快了吗"
帧级健康：FPS 百分位（p1 / p5 / p50）与 jank 日志，交叉验证体验改善
原始逐帧数据在服务端归约，AI 只接收 top-N 排行与 diff 结果，不占上下文。
# 函数耗时（主路径）—— 直连游戏内嵌的原生 Tracy server
AI (Claude) --MCP/stdio--> mcdk-mcp-tracy --TCP 8086--> 游戏内嵌原生 Tracy server
└─ bin/tracy-capture.exe + tracy-csvexport.exe
# 帧率 / jank（辅助路径）—— 经 MCDK 注入 get_Fps()
AI --MCP/stdio--> mcdk-mcp-tracy --MCP/SSE--> MCDK(mcdk.exe) --execute_code--> 游戏(Python2)函数耗时直连原生 ModPC Tracy（8086），不管是通过MCDK还是MC Studio启动的游戏：只要游戏启动没关闭就能抓取性能消耗信息。
采集覆盖窗口内全部已插桩 zone（含客户端 MAIN_THREAD 与 MC_SERVER 线程）。
采样时建议跑图/搭建场景测压：Tracy 只记录窗口内实际执行的代码，不建议静止不动。
bin/的 CLI 取自 Tracy v0.11.1 官方 Windows 包，版本须与游戏内嵌的 Tracy client 一致（协议版本敏感）；换游戏版本时同步替换。
Related MCP server: memorylens-mcp
游戏在运行，内嵌原生 Tracy server 监听 8086（用 tracy-profiler.exe GUI 能连上即确认）。
bin/tracy-capture.exe、bin/tracy-csvexport.exe 存在（随仓库附带；可用 TRACY_BIN_DIR 指向别处）。
（仅 tracy_jank_fps 需要） 游戏由 MCDK（mcdk.exe）启动，工程 .mcdev.json 开了 MCP：
{ "mcp_server_config": { "enabled": true, "server_ip": "localhost", "server_port": 19133 } }Python 3.10+（开发用 3.13），推荐 uv。
uv --directory <path>/mcdk-mcp-tracy sync # 装依赖 + 建 .venv
uv --directory <path>/mcdk-mcp-tracy run pytest -q # 自检，应 36 passed（无需游戏）claude mcp add mcdk-mcp-tracy --scope user -- \
"<path>/mcdk-mcp-tracy/.venv/Scripts/python.exe" -m mcdk_mcp_tracy \
--stdio --mcdk-url http://127.0.0.1:19133直接用 venv 里的 python.exe，不依赖 PATH。
--mcdk-url 仅 tracy_jank_fps 用得到；也可换成 --project-dir <MOD工程> 按其 .mcdev.json
自动找端口（优先级：--mcdk-url > --mcdev-json > --project-dir > $MCDK_MCDEV_JSON > 从 CWD 向上找）。
注册后新开会话才会出现 mcp__mcdk-mcp-tracy__* 工具。
卸载：claude mcp remove mcdk-mcp-tracy --scope user。
推荐一并安装配套技能：把 skills/mcdk-tracy-profiling/ 整个目录拷到 ~/.claude/skills/，
AI 会自动按下面的人机协作流程工作（先对齐采样计划，报告后由你拍板再改代码）。
codex mcp add mcdk-mcp-tracy -- \
"<path>/mcdk-mcp-tracy/.venv/Scripts/python.exe" -m mcdk_mcp_tracy \
--stdio --mcdk-url http://127.0.0.1:19133Codex 会将服务器写入用户级 ~/.codex/config.toml，无需 --scope user。
参数含义和寻址优先级与上方 Claude Code 配置相同；不需帧率 / jank 采样时可省略
--mcdk-url。
运行 codex mcp list 确认已注册；注册后新开 Codex 会话（IDE 扩展中需重启扩展）
即可使用 mcp__mcdk-mcp-tracy__* 工具。
卸载：codex mcp remove mcdk-mcp-tracy。
推荐一并安装配套技能：把 skills/mcdk-tracy-profiling/ 整个目录拷到 ~/.codex/skills/。
负载要你亲自在游戏里触发，改代码要你拍板——AI 驱动流程，关键节点等你：
探针：tracy_status()，确认 8086 可达 + CLI 齐全。
对齐采样计划：AI 先问你采样时长——10 秒（瞬时逻辑：开 UI、放技能）／30 秒（常规 玩法、跑图）／60 秒（长周期系统、复现偶发卡顿）／自定义（≤60）——以及准备触发的场景 （跑图、刷实体、开打、跑机器……），你就位后才开采。
基线采样：你在游戏里触发玩法，AI 执行
tracy_native_capture(seconds=<约定>, name_contains="YourMod", label="before")。
热点报告（对话正文输出）：热点排行（self / calls / 每帧均摊 / 单次均摊，必要时
tracy_get_function_costs 细查）+ 按性价比排序的优化计划——每条含根因、改法、预期收益
（估算 ms）、风险与改动量；改动小收益高的在前，动底层影响向下兼容的在后。你选定做哪几条。
改代码 + 复测：AI 按你选的方案改热点，同场景同时长再抓 label="after"。
diff 验收：tracy_diff_captures(base_id, new_id, metric="self")，delta_ms 为负 = 变快，
按毫秒和百分比回报实际收益。（可选：tracy_jank_fps FPS 百分位交叉验证，仅 MCDK）
采样返回（已按 self 耗时降序）：
{ "ok": true, "capture_id": "cap-1", "frames": 2632, "zones": 645899, "unit": "ms",
"total_self_ms": 327.0,
"top": [ { "name": "onRenderTick @ YourMod.Client.Main",
"self_ms": 134.2, "total_ms": 328.1, "calls": 2628 } ] }diff 返回：
{ "ok": true, "metric": "self",
"summary": { "base_total_ms": 86.4, "new_total_ms": 61.0, "delta_ms": -25.4, "pct": -29.4 },
"improved": [ { "name": "YourMod.combat.update", "delta_ms": -16.8, "base_ms": 21.3, "new_ms": 4.5 } ],
"regressed": [], "added": [], "removed": [] }目标函数出现在 improved、summary.pct 下降，即优化生效。
技能自带七份按症状索引的优化模式参考（AI 生成第 4 步优化计划时按需查阅；你也可以直接翻着看）。 所有模式按"采样症状 → 改法"组织、附可移植代码骨架，来自官方性能优化指南与已上线大型 MOD 的 实战验证——例如负缓存实测省 ~720ms/10s、配置存储改造内存 715MB → 224MB、客户端实体可见包围盒按档给 −2.77 ms/帧。
参考文件 | 覆盖模式 | 对应症状 |
组件全局缓存、降频+加盐+质数间隔、事件化替代轮询、分帧、单播替代广播、Python 微优化、调色板批量放置方块、配置内存与加载 | tick / 组件创建 / 通信热点；批量摆方块尖峰、启动慢、内存高 | |
负缓存、脏驱动 O(dirty)、值比对早退、同 tick 快照短路、有序调度池（定时器）、lazyTick 分频、frame-drain 分帧、静止短路、超距休眠、dead-reckoning、节流广播、落盘节流 | 多实体联动 / 渲染同步 / 持久化 / 高频定时器类热点 | |
可视区格子池+分页虚拟化、控件句柄缓存、显隐替代增删、值比对刷新、轻重分离+防抖、搜索索引预建、懒加载+分帧注册 | UI 打开慢 / 翻页搜索卡顿 / 界面常驻掉帧 | |
step/mix 消分支、精度限定符（含 iOS/Android 真机差异）、计算下移顶点/CPU、减 inverse/纹理/噪声、全屏后处理与 Bloom 降载、GLSL ES 兼容写法、#ifdef 多档位、热重载+帧率验证 | MOD 函数不贵但 FPS 低、引擎渲染 zone 占大头 | |
特效 Mesh 减面、移动端模型分级、透明残影+overdraw 控制 | 特效/模型一多就掉帧、近距离看角色掉帧 | |
可见包围盒按档给、多单元打包减实体、按规模分档、资产生成器硬断言、锚点与光照采样 | MOD 自建的客户端实体一多就掉帧 | |
天花板法、同场景 A/B monkey-patch、基线漂移、±5% 噪声底、成本模型回代验证 | Tracy 看不到的渲染类改动，下结论 / 报收益之前 |
工具 | 作用 | 关键参数 |
| 先跑。探测 8086 可达性、bundled CLI、MCDK 端点（信息性） |
|
| 核心。抓函数耗时 top-N，存为 |
|
| 从某次 capture 查函数成本（self/total/calls） |
|
| 前后两次 capture 按函数对比 |
|
| 帧级健康（仅 MCDK，MCStudio启动不可用）：FPS 百分位 / jank 日志 |
|
| 列出已存 capture，方便挑 id 做 diff | 无 |
统一返回：成功 {"ok": true, ...}，失败 {"ok": false, "reason": "...", "error": "..."}。
采样期间制造真实负载：站到卡顿场景、开打、刷实体、跑机器——要测什么就让游戏跑什么。
用 name_contains 聚焦自己的 MOD：函数显示为 "函数名 @ 源文件"，按脚本包前缀过滤；
过滤只影响 inline 返回，全量数据仍存进 capture，事后可再查。
diff 要可比：前后两次用尽量一致的玩法 + 相同 seconds，否则 delta 不可信。
结论用数字说话：优化是否生效看 improved / summary.pct，不凭体感。
Tracy 版本匹配：换游戏版本时同步替换 bin/ 的 CLI（当前 v0.11.1）。
现象 | 含义 | 怎么修 |
| 连不上 8086 | 确认游戏在跑且内嵌 Tracy；用 tracy-profiler GUI 验证；查 |
| 缺 bundled CLI | 确认 |
capture 返回空 + | 窗口内没负载 | 采样时让游戏真的跑要测的逻辑 |
| 连不上 MCDK | 确认游戏由 MCDK 启动、19133 在跑 |
| capture 已淘汰（只留最近 ~20 个） | 重新抓样拿新 id |
| 参数非法（如 | 按文档改参数 |
uv --directory mcdk-mcp-tracy run pytest -q # 36 passed，无需游戏
# 若 uv 在中文路径下报 trampoline 错误，改用：
./.venv/Scripts/python.exe -m pytest -qAI 工作流策略见 skills/mcdk-tracy-profiling/SKILL.md
Diff two captures by function to validate an optimization.
Negative delta = faster. Returns improved / regressed / added / removed plus overall movement (base vs new total, delta, pct).
Args: base_id: the "before" capture id (required). new_id: the "after" capture id (required). metric: 'self' (default) or 'total'. top_n: max rows per list (default 25).
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| metric | No | self | |
| new_id | Yes | ||
| base_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by explaining the meaning of negative delta ('faster') and listing the return categories. It does not contradict the readOnlyHint and idempotentHint, and provides useful behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a purpose line, a line about delta meaning, a list of return categories, and a clear Args section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and return categories adequately. However, it could be improved by mentioning error handling or invalid capture IDs, though the output schema likely covers return types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes an Args section that explains each parameter's purpose (e.g., base_id/new_id are capture IDs, metric options, top_n max rows). This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool diffs two captures by function to validate an optimization, and lists the output categories (improved/regressed/added/removed). It is distinct from siblings like tracy_list_captures and tracy_get_function_costs, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for validating optimizations but does not explicitly state when to use this tool versus alternatives (e.g., for a single capture, use tracy_get_function_costs). No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query per-function self/total/calls from a stored capture.
Pure server-side slice (no game call). Filter by exact names and/or a
substring; without a filter, returns the top limit by self-time.
Args: capture_id: id from tracy_native_capture (required). names: exact function names to include. name_contains: case-insensitive substring filter (e.g. your mod prefix). limit: max rows to return (default 50).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| names | No | ||
| capture_id | Yes | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds 'Pure server-side slice (no game call)' and explains it queries a stored capture. No contradictions, but behavior beyond annotations is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences) with a clear structure: main purpose, filtering behavior, then parameter list. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to detail return values. It covers purpose, safety (server-side), and parameter semantics completely for a query tool with annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: capture_id is required, names for exact match, name_contains for case-insensitive substring, limit default 50. Adds significant meaning beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries per-function self/total/calls from a stored capture. It distinguishes itself from sibling tools like tracy_diff_captures and tracy_jank_fps by focusing on a single capture analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to filter results (exact names, substring, or default top limit) and notes it's a pure server-side operation. However, it does not explicitly contrast with sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Frame-level health, complementing the per-function view.
Actions:
sample_fps: poll get_Fps()/get_frame_time() over the window; returns avg/min/max and p1/p5/p50 percentiles.
read_jank_logs: scrape recent jank/profile lines from MCDK logs.
Args: action: one of sample_fps | read_jank_logs (required). side: 'client' or 'server'. duration_seconds: window for sample_fps (default 5). log_lines: lines to scan for read_jank_logs (default 200).
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | client | |
| action | Yes | ||
| log_lines | No | ||
| duration_seconds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes read-like actions (polling, scraping) but annotations indicate readOnlyHint=false, creating a potential contradiction. No additional behavioral context (e.g., side effects, state changes) is provided beyond the actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with a brief overview, bulleted actions, and listed args. It could be slightly more concise but avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity, the description sufficiently explains tool usage but lacks guidance on when to choose each action or how output relates to usage. The presence of an output schema (unseen) partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaningful explanation for all parameters: action (with enumerated values), side, duration_seconds, and log_lines, giving context not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Frame-level health, complementing the per-function view' and lists two specific actions (sample_fps and read_jank_logs), which distinguishes it from sibling tools focused on captures, function costs, and status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (frame-level health vs. per-function view) but does not explicitly state when to use this tool versus siblings, nor does it provide exclusions or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List stored captures (id, label, side, totals, timestamp) for diffing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the returned fields and the context of diffing. It does not contradict annotations, and the provided details go beyond the structured annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys all essential information without unnecessary words. It is front-loaded with the primary action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, an existing output schema (though not detailed), and clear annotations, the description adequately explains the tool's purpose and output. It specifies the returned fields and the diffing context, which is sufficient for this simple tool. No major gaps are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds meaning by listing the fields that will be returned (id, label, side, totals, timestamp), which is useful context even though it is not parameter-related. For zero-parameter tools, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'stored captures', and explicitly names the fields (id, label, side, totals, timestamp). It also indicates the purpose ('for diffing'), which distinguishes it from the sibling tool tracy_diff_captures that likely performs the actual diff operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for diffing but does not provide explicit when-to-use or when-not-to guidance. Since there are no parameters, the tool is straightforward, but it could mention that it lists all available captures without filtering. No alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture function timings from the game's NATIVE Tracy server (TCP 8086).
Use this once tracy_status reports native_tracy.reachable=true and
bin_present=true. The client embeds a native Tracy server (the one the
tracy-profiler GUI connects to) even on builds where the Python profiler
binding is missing. This drives the bundled tracy-capture / tracy-csvexport
CLIs; no module whitelist is needed (native Tracy traces every zone, across
the client's MAIN_THREAD and MC_SERVER threads).
Drive the gameplay you want to measure DURING the window. The returned
capture_id plugs into tracy_get_function_costs / tracy_diff_captures
exactly like an in-game capture.
Args: seconds: capture window, 0 < s <= 60 (default 5). name_contains: case-insensitive filter, e.g. 'arrisCreate' to keep only your mod's functions (matched against "name @ src_file"). top_n: rows returned inline (default 25; the full set is stored for later get_function_costs / diff queries). address/port: native Tracy endpoint (default 127.0.0.1:8086). label: tag for diffing, e.g. 'before' / 'after'.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| label | No | ||
| top_n | No | ||
| address | No | 127.0.0.1 | |
| seconds | No | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds behavioral details: it drives CLIs, traces across main_thread and MC_SERVER threads, and requires no whitelist. It does not contradict annotations and provides meaningful context, though it does not specify blocking behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, usage condition, and parameter details. It is concise enough while including necessary guidance, but could be slightly shorter without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and presence of output schema, the description covers prerequisites, usage flow, parameter meaning, and how the output (capture_id) integrates with sibling tools. It adequately informs the agent for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains each parameter: seconds range and default, name_contains filter with example, top_n default, address/port default, and label for diffing. This adds significant semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures function timings from a native Tracy server on TCP 8086. It distinguishes itself from siblings like tracy_get_function_costs and tracy_status by specifying the capture action and prerequisite conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: use after tracy_status reports reachable and bin_present, and drive gameplay during the capture window. It also explains the output (capture_id) integrates with other tools, offering clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Probe whether native-Tracy profiling is usable on the running game.
RUN THIS FIRST. The capture path used by this server is the game's
embedded native Tracy server (TCP 8086), driven by the bundled
tracy-capture / tracy-csvexport CLIs. It does NOT use the Python
_utility.getCpuFrameData binding (absent on most release builds) and
does NOT go through MCDK. Reports:
native_tracy.reachable — can we open a TCP connection to 8086? (the
tracy-profiler GUI connects to the same port)
bin_present — are the bundled Tracy CLIs available?
mcdk — MCDK MCP endpoint, informational only (just tracy_jank_fps
needs it; native capture is independent). Best-effort.
ok is true when the native path is ready (reachable + bin present);
otherwise reason/hint pinpoint the broken leg.
Args: address/port: native Tracy endpoint (default 127.0.0.1:8086). project_dir: optional path whose .mcdev.json gives MCDK's MCP port.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | ||
| address | No | 127.0.0.1 | |
| project_dir | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true. Description adds details about what is probed (reachable, bin_present, mcdk) and explains the underlying mechanism (native Tracy server, TCP 8086, bundled CLIs), going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: opening sentence, 'RUN THIS FIRST', explanation of reports, then Args. Every sentence adds value, no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and existence of output schema, the description covers purpose, usage, behavioral details, and parameters. Output schema fields are mentioned, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains parameters in the 'Args' section: address/port defaults, project_dir optional for MCDK port. This adds meaning beyond the schema's default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Probe whether native-Tracy profiling is usable on the running game.' It specifies the verb (probe), resource (native-Tracy profiling), and distinguishes from sibling tools like tracy_native_capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'RUN THIS FIRST' and explains that it does NOT use the Python binding or MCDK, providing clear guidance on when to use this tool before other Tracy tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0tracy_diff_capturestracy_get_function_coststracy_jank_fpstracy_list_capturestracy_native_capturetracy_statusScored across 6 tools
Each tool has a clearly distinct purpose: checking readiness, listing captures, capturing, querying costs, diffing captures, and monitoring frame health. No overlapping functionalities.
All tools follow the consistent 'tracy_' prefix followed by a verb_noun pattern (e.g., tracy_status, tracy_list_captures, tracy_native_capture, tracy_get_function_costs, tracy_diff_captures, tracy_jank_fps).
Six tools cover the profiling domain comprehensively without being excessive. Each tool is essential for the core workflow: readiness check, capture, query, diff, and frame-level analysis.
The tool surface covers the main profiling workflow (status, capture, costs, diff, frame health). A minor gap is the lack of a tool to delete or manage stored captures, but the set is complete for common tasks.
MCP server for Qwen Image 3 AI image generation
Cloud-hosted MCP server for durable AI memory
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for Grok Imagine AI video generation
