What can you do with this server?

The claude-init server lets you analyze a repository and manage AI context files for all major coding assistants — entirely locally (no API key required by default). * analyze_project – Scan a repository by absolute path and receive a structured JSON report covering: * Tech stack (language, framework, runtime, package manager, database, test runner, build/monorepo tool, CI provider) * Commands (install, dev, build, test, lint, format, Makefile/Taskfile targets, CI workflow commands) * Project structure (trimmed file tree, entry points, config files) * Code conventions (strict mode, linter, formatter, import style, commit convention) * Environment variables (parsed from .env.example with descriptions) * Git metadata (default branch, remote, top authors, frequently changed files) * generate_context_files – Generate AI context files (e.g., CLAUDE.md, AGENTS.md, GEMINI.md, cursor/windsurf/cline rules, copilot, etc.) for supported tools: claude, agents, cursor, windsurf, cline, continue, kilocode, trae, copilot, gemini, aider, junie, warp. Options include targeting specific tools, a custom output directory, overwriting existing files, and recursing into monorepo workspaces. * check_context_files – Verify whether existing AI context files are up to date with the current project state, reporting a per-file status of ok, stale, or missing. Supports filtering by target tools, custom output directories, and monorepo workspace recursion — useful for CI/hooks.

Which integrations are available for this server?

Generates AGENTS.md which is read by Amp and other agents to understand project context. Generates .windsurf/rules/project.md for the Windsurf IDE by Codeium, providing project rules and context. Generates .github/copilot-instructions.md to provide GitHub Copilot with project-specific instructions and context. Generates .junie/guidelines.md for JetBrains Junie, providing project guidelines and context. Generates AGENTS.md which is read by OpenAI Codex and other agents to understand project context. Generates WARP.md to provide context for Warp terminal's AI features.

claude-init

by horiastanxd

Overview Schema Related Servers Score Discussions

TypeScript

Local

claude-init

One command generates the AI context files for every coding assistant - from one repo scan.

CLAUDE.md · AGENTS.md · Cursor · Windsurf · Cline · Continue · Kilo Code · Trae · Copilot · GEMINI.md · Aider · Junie · Warp

npx @horiastanxd/claude-init

npm version license node Glama MCP

Website · npm · Changelog

claude-init demo

Why

Every AI coding tool wants a file describing your project - and they all use a different name and format. Keeping over a dozen of them in sync by hand is busywork, and the moment your stack changes they go stale.

claude-init scans your repo once - stack, scripts, structure, env vars, conventions, git - and writes all of them in seconds. No API key, no network, 100% local.

$ npx @horiastanxd/claude-init
✔ Analyzed my-app (TypeScript, Next.js)
  + CLAUDE.md
  + AGENTS.md
  + .cursor/rules/project.mdc
  + .windsurf/rules/project.md
  + .clinerules/project.md
  + .continue/rules/project.md
  + .kilocode/rules/project.md
  + .trae/rules/project_rules.md
  + .github/copilot-instructions.md
  + GEMINI.md
  + CONVENTIONS.md
  + .junie/guidelines.md
  + WARP.md

Done. 13 file(s) generated.

Related MCP server: Graft

Supported tools

Target (`-t`)	File written	Read by
`claude`	`CLAUDE.md`	Claude Code
`agents`	`AGENTS.md`	OpenAI Codex, Jules, Amp, Zed, Devin, RooCode, Factory, +20 agents
`cursor`	`.cursor/rules/project.mdc`	Cursor (modern `.mdc` rules)
`windsurf`	`.windsurf/rules/project.md`	Windsurf / Codeium
`cline`	`.clinerules/project.md`	Cline, Roo Code
`continue`	`.continue/rules/project.md`	Continue
`kilocode`	`.kilocode/rules/project.md`	Kilo Code
`trae`	`.trae/rules/project_rules.md`	Trae IDE
`copilot`	`.github/copilot-instructions.md`	GitHub Copilot
`gemini`	`GEMINI.md`	Gemini CLI
`aider`	`CONVENTIONS.md`	Aider
`junie`	`.junie/guidelines.md`	JetBrains Junie
`warp`	`WARP.md`	Warp terminal

AGENTS.md is becoming the shared standard - one file read by a growing list of agents. claude-init generates it alongside each tool's native format, so you are covered both ways.

Usage

npx @horiastanxd/claude-init                      # generate everything in the current repo
npx @horiastanxd/claude-init ./path/to/repo       # analyze a different directory
npx @horiastanxd/claude-init -t claude,cursor     # only specific tools
npx @horiastanxd/claude-init --overwrite          # refresh files that already exist
npx @horiastanxd/claude-init --dry-run            # print the analysis as JSON, write nothing
npx @horiastanxd/claude-init --recurse            # also generate into each workspace package (monorepo)
npx @horiastanxd/claude-init --enrich             # opt-in: sharpen the description with an LLM (needs ANTHROPIC_API_KEY)
npx @horiastanxd/claude-init list                 # show all targets and their paths

By default existing files are left untouched - re-run with --overwrite to refresh them after your stack changes.

claude-init [generate] [dir]   analyze a repo and write context files (default)
claude-init check [dir]        verify files are up to date (exit 1 on drift)
claude-init list               list supported targets
claude-init mcp                run as an MCP server over stdio

Options:
  -t, --targets <list>   comma-separated target ids, or "all"   (default: all)
  -o, --output <dir>     output directory                        (default: .)
  --overwrite            overwrite existing files
  --dry-run              print the analysis as JSON, write nothing
  --recurse              also generate into each workspace package (monorepo)
  --enrich               use an LLM to enrich the project description (opt-in)
  --enrich-model <model> model for --enrich            (default: claude-opus-4-8)

--enrich is the one feature that leaves your machine, and it is off by default - everything else is 100% local. It needs ANTHROPIC_API_KEY and the Anthropic SDK (npm install @anthropic-ai/sdk); if either is missing, generation continues without enrichment, so nothing breaks.

For a monorepo, --recurse reads the workspaces from package.json (workspaces) or pnpm-workspace.yaml, then generates context files in the root and in each package, analyzing every package on its own. It works for both generate --recurse and check --recurse (and the MCP tools take a recurse flag).

Keep context files fresh

claude-init check regenerates in memory and compares against disk, exiting non-zero on drift. Wire it into CI or a pre-commit hook so your context never rots.

pre-commit (.git/hooks/pre-commit or pre-commit):

npx @horiastanxd/claude-init check || {
  echo "AI context files are stale - run: npx @horiastanxd/claude-init --overwrite"
  exit 1
}

GitHub Actions - run the CLI directly:

- run: npx @horiastanxd/claude-init check

or use the action:

- uses: horiastanxd/claude-init@v1
  with:
    command: check   # or "generate"
    targets: all     # comma-separated ids, or "all"
    # args: --overwrite --recurse

Example output

# my-app

A demo application.

## Stack
- Language: TypeScript
- Framework: Next.js
- Runtime: Node.js
- Package manager: pnpm
- Database: Prisma ORM
- Testing: Vitest

## Commands
```bash
pnpm install   # install
pnpm run dev   # dev
pnpm run test  # test

Code conventions

TypeScript strict mode is enabled - keep full type safety, avoid any.
Linter: ESLint. Run it before committing.
Formatter: Prettier. Do not hand-format against it.

Environment variables

Copy .env.example to .env and set:

DATABASE_URL (required) - Postgres connection string


</details>

## MCP server

`claude-init` also runs as a [Model Context Protocol](https://modelcontextprotocol.io)
server, so an agent can analyze a repo and write the context files itself.

```bash
# Claude Code
claude mcp add claude-init -- npx @horiastanxd/claude-init --mcp

Tools exposed: analyze_project, generate_context_files, check_context_files.

What gets detected

Stack - language, framework, runtime, package manager, database, test runner, build / monorepo tool, CI provider
Commands - install / dev / build / test / lint / format, plus other scripts, Makefile / justfile / Taskfile targets, and commands from .github/workflows
Structure - a trimmed file tree, entry points, config files
Conventions - strict mode, linter, formatter, import style, commit convention
Env vars - parsed from .env.example, with inline comments as descriptions
Git - default branch, remote, top authors, frequently changed files

Languages: JS/TS (npm, pnpm, yarn, bun), TypeScript on Deno, Python (pip, uv, poetry), Rust (cargo), Go (modules), Java/Kotlin (Maven, Gradle), C#/.NET (NuGet), Elixir (mix), Dart (pub), Ruby (Bundler), and PHP (Composer).

Frameworks detected include Next.js, Remix, Astro, Angular, Gatsby, NestJS, Express, Fastify, Hono, SvelteKit, Nuxt, Vue, Svelte, React (JS/TS); Fresh (Deno); FastAPI, Django, Flask (Python); Axum, Actix, Rocket (Rust); Gin, Fiber, Echo (Go); Spring Boot (Java); ASP.NET Core (.NET); Phoenix (Elixir); Android (Kotlin); Flutter (Dart); Rails, Sinatra (Ruby); and Laravel, Symfony (PHP).

It also recognizes databases (PostgreSQL, MySQL, SQLite, MongoDB, Redis, Supabase, Prisma, Drizzle), monorepo/build tooling (Nx, Turborepo, Lerna, Vite, esbuild, webpack), and the CI provider (GitHub Actions, GitLab CI, CircleCI, Azure Pipelines, Jenkins, Travis, Drone).

Use as a library

import { analyzeProject, generateClaudeMd, buildFiles } from 'claude-init';

const analysis = await analyzeProject(process.cwd());
const md = generateClaudeMd(analysis);

// or render every target in memory
for (const file of buildFiles(analysis)) {
  console.log(file.relPath, file.content.length);
}

Development

npm install
npm run dev -- --dry-run   # run from source
npm test
npm run build

Contributions welcome - adding a new tool is usually a single entry in src/generators/registry.ts. See CONTRIBUTING.md.

Roadmap

More tools as their formats stabilize

Ideas and PRs welcome.

Star History

License

MIT

Available Tools

3 tools

analyze_projectB

Analyze a repository (tech stack, commands, structure, env vars, git) and return structured JSON.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute path to the project directory

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It does not state whether the tool is read-only, requires permissions, or makes network calls. 'Analyze' could imply mutation, but this is unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence, concise and front-loaded with the main action. However, it could benefit from a more structured format for better readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool analyzes multiple aspects and has no output schema, the description lacks details on the returned JSON structure, prerequisites (e.g., git installed), and behavioral constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has full coverage for the single parameter 'path' with a description. The tool description adds no additional meaning beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes a repository, listing specific aspects (tech stack, commands, structure, env vars, git) and the output format (structured JSON). It distinguishes from sibling tools like check_context_files and generate_context_files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no prerequisites, and no mention of when not to use it. The description lacks context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_context_filesA

Check whether the existing AI context files match the current repository. Reports per-file ok/stale/missing.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Absolute path to the project directory
`targets`	No
`outputDir`	No	Directory holding the files (default: the project path)
`recurse`	No	Also check each workspace package for a monorepo (default: false)

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description carries full burden. It discloses that tool checks files and reports status (ok/stale/missing). However, no details on error behavior, permissions needed, or side effects. Adequate for a read-only check.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, front-loaded with action and result. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Returns minimal info on output ('per-file status'), but lacks details on output format (e.g., list, object). For a 4-param tool with no output schema, description is barely adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75% but the 'targets' parameter has enum values without description. The tool description does not explain what 'targets' represent. Thus, for the unexplained parameter, description adds no value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'check' and resource 'existing AI context files' with clear outcome ('Reports per-file ok/stale/missing'). Clearly distinguishes from siblings 'analyze_project' (broader) and 'generate_context_files' (creation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage for verifying context file freshness but does not explicitly state when to use vs alternatives or mention when not to use. No exclusions or prerequisites provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_context_filesA

Generate AI context files (CLAUDE.md, AGENTS.md, Cursor/Windsurf/Cline rules, GEMINI.md, Copilot, and more) for a repository.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Absolute path to the project directory
`targets`	No	Which targets to generate (default: all)
`outputDir`	No	Output directory (default: the project path)
`overwrite`	No	Overwrite existing files (default: false)
`recurse`	No	Also generate into each workspace package for a monorepo (default: false)

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior. It only states file generation but does not mention that files are created/modified on disk, potential for overwriting (though schema has 'overwrite'), or that it reads the project structure. The agent cannot fully anticipate side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with key purpose and examples. It is concise but could be slightly restructured to highlight key aspects more effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple targets, monorepo support) and lack of output schema or annotations, the description is minimal. It covers the basic 'what' but omits context about how generation works, what it reads, or what the output looks like.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it only lists example file types without explaining how parameters like 'recurse' or 'overwrite' affect behavior or when to use them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the exact action 'generate AI context files' and lists concrete file types (CLAUDE.md, AGENTS.md, etc.), clearly distinguishing from sibling tools 'analyze_project' and 'check_context_files' which imply different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies generation of context files, and sibling tool names ('analyze_project', 'check_context_files') provide implicit differentiation. However, no explicit guidance on when to choose this over alternatives or prerequisites like needing a project path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.8.0Jun 19, 2026
- First observedanalyze_project
- First observedcheck_context_files
- First observedgenerate_context_files

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: analyze the project, check existing context files, and generate new ones. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (analyze_project, check_context_files, generate_context_files) using snake_case, making them predictable and easy to parse.

Tool Count5/5

With only 3 tools, the set is concise and well-scoped for the purpose of initializing AI context for a repository. Each tool serves a necessary function without redundancy.

Completeness5/5

The set covers the full workflow: analyzing the repository, checking existing context files, and generating/initializing them. No obvious gaps are present for the stated purpose.

Maintenance

ActivityStale

ResponsivenessResponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Contexter
io.github.maaakso
Share one project context across ChatGPT, Claude, Telegram and any MCP client.
Knowledge & Memory Note Taking
1
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
mcp A
ai.promptarch
Research-backed linting + generation for agent context files (CLAUDE.md, AGENTS.md, Cursor rules).
Agent Orchestration Developer Tools
32

Related MCP Servers

@lex-tools/codebase-contextofficial
Code Analysis Developer Tools Documentation Access
lex-tools
A
license
A
quality
D
maintenance
A Model Context Protocol (MCP) server designed to easily dump your codebase context into Large Language Models (LLMs).
Updated a year ago (2025-08-02 06:43 UTC)
1
12
3
Apache 2.0
Graft
Code Analysis Developer Tools
amaar-mc
A
license
B
quality
D
maintenance
Local-first codebase context engine that parses code into a ranked dependency graph and serves it to AI tools via MCP for deep structural understanding.
Updated 5 months ago (2026-03-28 20:18 UTC)
5
27
1
MIT
ProjectBrain
Code Analysis Developer Tools
yinshaojun001
A
license
B
quality
B
maintenance
Local MCP server providing project cognition capabilities for AI coding agents, including context packs, impact analysis, and git diff review through stdio communication.
Updated 2 months ago (2026-06-30 07:01 UTC)
10
3
MIT
Reverie
Knowledge & Memory Developer Tools
seabearDEV
A
license
Not graded
quality
A
maintenance
CLI + MCP server that bootstraps persistent project context for any AI agent, storing structured information using hierarchical dot notation and exposing it via MCP tools for session-over-session knowledge growth.
Updated 12 days ago (2026-08-25 11:36 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/horiastanxd/claude-init'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

claude-init

Why

Supported tools

Usage

Keep context files fresh

Example output

Code conventions

Environment variables

What gets detected

Use as a library

Development

Roadmap

Star History

License

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@lex-tools/codebase-contextofficial

Graft

ProjectBrain

Reverie

Latest Blog Posts

MCP directory API