Click on "Install 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., "@Karpathy Guidelines MCP Server Review my code for over-engineering"
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.
基于 Andrej Karpathy 对 LLM 编码陷阱的观察，将编码行为准则封装为 MCP 工具，供 Claude Code 直接调用。
Related MCP server: Best Practices MCP Server
LLM 编码时常见的问题：代你做错误假设、过度复杂化代码、改动不该碰的代码、缺乏可验证的成功标准。
本项目将 Andrej Karpathy 提出的四大编码原则封装为 MCP（Model Context Protocol）服务器，提供两个工具：
get_guidelines — 加载完整的编码行为准则
review_code — 根据四大原则审查代码并给出改进建议
🔍 代码审查 — 自动检测过度工程、缺失测试、超出范围的改动等问题
📖 指南加载 — 一键获取完整的 Karpathy 编码准则
🔌 即插即用 — 标准 MCP 协议，兼容所有支持 MCP 的客户端
📦 npx 直接运行 — 无需手动下载，npx 一行命令搞定
Node.js >= 18
Claude Code 或其他 MCP 客户端
在 Claude Code 的 MCP 配置文件中添加：
全局配置（~/.claude/settings.json）：
{
"mcpServers": {
"karpathy-guidelines": {
"command": "npx",
"args": ["-y", "karpathy-guidelines-mcp"]
}
}
}项目级配置（.claude/settings.json）：
{
"mcpServers": {
"karpathy-guidelines": {
"command": "npx",
"args": ["-y", "karpathy-guidelines-mcp"]
}
}
}配置完成后重启 Claude Code 即可使用。
在编写代码前，让 Claude 加载行为准则：
帮我加载 karpathy 编码指南将代码交给 Claude 审查：
用 karpathy guidelines 审查一下这段代码：
function createUser(data) {
const validator = new UserValidator();
const transformer = new DataTransformer();
const repository = new UserRepository();
const result = validator.validate(data);
if (result.isValid) {
const transformed = transformer.transform(data);
return repository.save(transformed);
}
throw new ValidationError(result.errors);
}git clone https://github.com/Yangleduo00337788/Karpathy-Guidelines-MCP-Server.git
cd Karpathy-Guidelines-MCP-Server/mcp-server
npm install
node index.jsget_guidelines返回完整的 Karpathy 编码指南。
参数 | 类型 | 必填 | 说明 |
无 | - | - | - |
返回值： 完整的编码指南文本
review_code根据四大原则审查代码，返回结构化的审查意见。
参数 | 类型 | 必填 | 说明 |
|
| ✅ | 待审查的代码片段 |
|
| ❌ | 代码的用途说明（不提供会提示补充） |
返回值： 审查意见列表，包含问题描述和改进建议
检查规则：
原则 | 检查内容 |
Think Before Coding | 是否提供了足够的上下文和假设说明 |
Simplicity First | 代码行数是否过多，是否有过度抽象 |
Surgical Changes | 是否有超出请求范围的改动 |
Goal-Driven Execution | 是否有测试来验证代码 |
原则 | 核心理念 | 解决的问题 |
编码前思考 | 不要假设，不要隐藏困惑 | 错误假设、缺少权衡 |
简洁优先 | 用最少的代码解决问题 | 过度工程、臃肿抽象 |
精准修改 | 只碰必须碰的 | 无关编辑、改动不该碰的代码 |
目标驱动执行 | 定义成功标准，循环验证 | 模糊的成功标准、缺乏测试 |
Karpathy-Guidelines-MCP-Server/
├── mcp-server/
│ ├── index.js # MCP 服务器主文件
│ ├── package.json # 依赖配置
│ └── README.md # 本文件
├── skills/
│ └── karpathy-guidelines/
│ └── SKILL.md # 原始技能定义
├── CLAUDE.md # Claude Code 指南
└── README.md # 项目说明欢迎提交 Issue 和 Pull Request。
Fork 本仓库
创建特性分支：git checkout -b feature/your-feature
提交更改：git commit -m 'feat: add some feature'
推送分支：git push origin feature/your-feature
提交 Pull Request
遵循 Conventional Commits 规范：
feat: 新功能
fix: Bug 修复
docs: 文档更新
refactor: 代码重构
test: 测试相关
chore: 构建/工具相关
如果这个项目对你有帮助，欢迎 ⭐ Star 支持！
Returns the full Karpathy coding guidelines. Call this before writing or reviewing code to load the behavioral rules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool returns the guidelines but does not describe the format, size, or any side effects. Basic transparency is achieved, but could be more detailed.
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?
Two sentences, no wasted words. Purpose and usage are front-loaded. Excellent conciseness.
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?
For a simple retrieval tool with no parameters, output schema, or annotations, the description covers all necessary context: what it returns and when to call 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?
No parameters, so description does not need to add meaning beyond schema. Schema coverage is 100% trivially. Baseline 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?
Clearly states that the tool returns the full Karpathy coding guidelines, and explicitly says to call it before writing or reviewing code. Distinguishes from sibling tool 'review_code' by specifying the usage context.
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 states when to use: 'Call this before writing or reviewing code to load the behavioral rules.' Does not explicitly state when not to use, but the context is clear given the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review code against the 4 Karpathy principles: Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code snippet to review | |
| context | No | Optional context about what the code is supposed to do |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, description does not disclose whether this tool modifies state, requires permissions, or returns a report. Minimal behavioral info.
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?
Single sentence with front-loaded verb and resource list. Efficient but could benefit from structured outcomes.
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?
No output schema, description omits what the review result looks like (e.g., comments, pass/fail). Incomplete for single-param tool.
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 100%, baseline 3. Description adds no extra meaning beyond schema's parameter 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?
States verb 'Review code' and resource '4 Karpathy principles', distinguishing from sibling 'get_guidelines' which likely returns guidelines.
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?
No guidance on when to use this tool over sibling 'get_guidelines'. No when-not or prerequisites mentioned.
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. Dates show when Glama detected each change.
v1.0.0get_guidelinesreview_codeThe two tools have distinctly different purposes: one retrieves guidelines, the other reviews code. There is no overlap or ambiguity.
Both tools follow a consistent verb_noun pattern (get_guidelines, review_code), making naming predictable and clear.
Only two tools is minimal but sufficient for the focused domain of guideline retrieval and code review. It is borderline but acceptable.
The server covers its stated purpose completely: retrieving the full guidelines and reviewing code against them. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Research-backed linting + generation for agent context files (CLAUDE.md, AGENTS.md, Cursor rules).
Path-scoped team memories, rules and skills for Claude Code, Cursor, Codex and other MCP clients.
Lints + auto-fixes how AI coding agents discover any new product. 24 rules, 6 tools, score 0-100.
Serves your design system and coding standards to coding agents, so they stop guessing.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Yangleduo00337788/Karpathy-Guidelines-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
