Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Tiny sphere-physics engine for three.js games: spawn, step, raycast, InstancedMesh-ready positions
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"flit": {
"command": "npx",
"args": [
"-y",
"flit-physics"
]
}
}
}在终端中运行这条命令
claude mcp add flit -- npx -y flit-physics粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"flit": {
"command": "npx",
"args": [
"-y",
"flit-physics"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"flit": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"flit-physics"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月7日
注册名称已通过 GitHub 账户 brashler 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(0.2.2)于2个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Node.js。
同一分类中有:Spec Driven Development, Remote Desktop Commander, Python MCP
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Local-only Python MCP server for the Files.com API.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
Flit is a tiny little physics engine for 3js. It doesn't do much yet! but I believe!
Spheres, collisions, raycasts, gravity, and a spatial-hash broadphase — nothing more, on purpose. All simulation state lives in flat Float32Arrays (structure-of-arrays), so the CPU path doubles as the reference implementation for a future WebGPU compute backend: same buffers, same kernels, no re-architecting.
index: -1).THIRD_PARTY_NOTICES.md for provenance and licenses.Building a little three.js game or demo? Two ways in:
skills/flit/SKILL.md — copy the skills/flit/ directory into your agent's skills path (e.g. .claude/skills/, ~/.code_puppy/skills/). It carries the 30-second integration recipe, the MCP option, measured performance envelope, and contributor rules.npm run mcp, or point your client at it:{
"mcpServers": { "flit": { "command": "npx", "args": ["vite-node", "mcp/server.ts"], "cwd": " " } } }
Tools: flit_info, flit_reset (gravity/restitution/ground/bounds/ settleSpeed/heightfield), flit_spawn (rain/explosion/grid/fountain presets), flit_add_particles, flit_step, flit_state, flit_raycast — step/state return flat xyz positions shaped for InstancedMesh syncing plus settledCount, so you can watch a pile go quiet.
npm i flit-physics
import { World } from 'flit-physics';
const world = new World({ restitution: 0.4 }); // gravity and a floor at y=0 included
const ball = world.addParticle({ position: [0, 10, 0], radius: 0.5, mass: 1 });
// fixed timestep, e.g. from your rAF loop world.step(1 / 60);
// sync to three.js: positions is a live Float32Array, 3 floats per particle mesh.position.set( world.positions[ball * 3], world.positions[ball * 3 + 1], world.positions[ball * 3 + 2], );
Terrain and sleep are one option each:
import { Heightfield, World } from 'flit-physics';
const terrain = new Heightfield({ rows: 64, cols: 64, cellSize: 1, heights }); const world = new World({ groundY: null, heightfield: terrain }); // bodies collide with the terrain and settle on it; // world.raycast(...) reports terrain hits as index -1
// sleep is on by default (settleSpeed 0.01 m/s); opt out per world: const wideAwake = new World({ settleSpeed: 0 });
npm install
npm test # vitest npm run build # tsc -> dist/ npm run bench # broadphase + full-step micro-benchmarks npm run demo # three.js demo scene (vite dev server)
Deterministic seeds; numbers from a local dev machine, recorded at commit time (see commit messages for the full series, including rejected designs).
bench/broadphase.bench.ts — broadphase only, N=4096: xor-hash 3.4–3.7 ms (444 pairs, ~90% collision bloat) → Morton keys with ordered probing 3.5–3.7 ms (234 pairs, exact).bench/world.bench.ts — full World.step, N=1024: xor-hash 0.85 ms/step → Morton ordered-probing 0.83 ms/step → 0.93 ms/step with the sequential-impulse velocity solver (4 iterations + LUT friction). Exact keys, real contacts, +11%.bench/scaling.bench.ts — two regimes. Fixed box (density rises): pairs scale ~N² from crowding physics. Scaled box (constant *spawn* density): flat O(N) ≈ 1.2 ms per 1000 through N=8000 while bodies are scattered. With gravity on, everything rains into a dense floor pile over ~2-4s (WARMUP=240 to reproduce) — and since 0.3.0 the pile SETTLES: 34.2 → 9.2 ms/step at N=8000 (3.7x, inside the 60fps budget) as bodies fall asleep bottom-up. Settled bodies are skipped by integration, planes, and mutual contacts until a >1 m/s impact wakes them. (docs/issues/001 — resolved; brief kept for the analysis and the remaining ideas: warm starting, adaptive iterations.)bench/raycast.bench.ts — 2000 seeded rays at N=4096: 63–68 µs/ray (vs ~160 µs for a brute-force O(N) oracle at the same density; the grid walk pulls further ahead as N grows).bench/morton-libs.bench.ts — codec bake-off vs npm libs (npm run bench:libs): ours 3.8 ns/encode, fast-morton MB 26.1, fast-morton LUT 43.8, @thi.ng/morton 539.9. In-house wins; the libs stay as devDependencies purely so the bake-off stays runnable.bench/threaded.bench.ts — WorkerWorld over a real worker thread (SAB ping-pong): kick() costs 0.014 ms on the main thread; with a 4 ms render workload a frame costs 8.84 ms pipelined vs 14.96 ms serial at N=8192 (113 fps vs 67). At N=1024 the 0.8 ms step hides entirely behind render (4.03 vs 4.80 ms).npm run demo, 220 balls in a box (?terrain for heightfield hills, ?n=8000 for load testing)WorkerWorld: kick/waitForUpdate, SAB ping-pong zero-copy rendering3173a6f for the analysisMIT — see LICENSE. Third-party portions and their licenses are listed in THIRD_PARTY_NOTICES.md.