A remarkably well-architected dual-stack monorepo with exemplary agent guidance and clean separation of concerns.
last scored 2026-09-15 · both lenses
Readiness lenses
The same repo, two ways: how ready it is for an AI coding agent, and for a human newcomer. Switch lenses to see each one's score and checks.
How ready the repo is for an AI coding agent to read, build, and operate it.
85 / 10026 of 43 checks passed across 6 categories.
Machine Orientation
95Outstanding machine orientation with comprehensive root and package-level agent guidance.
The repository provides exceptional machine orientation with a top-tier CLAUDE.md at the root, a dedicated agent guide in src/everything/AGENTS.md, an informative architecture doc, and clear package-level build and test instructions for both TypeScript and Python servers. It easily clears the Solid to Exemplary band (90-100).
Reproducible Setup
80Reproducible setup is solid and well-documented via CLAUDE.md, though split across Node and Python ecosystems without a unified runner.
The repository provides precise workspace configuration, lockfiles for both Node (package-lock.json) and Python (uv.lock), and comprehensive CI workflows with explicit build and test scripts, clearing the Solid band. However, individual package pins are absent at the root level and there is no devcontainer or environment file template.
Code Navigability
85Clear module boundaries and excellent documentation make navigating and localizing code very straightforward.
Code nav is Solid (85/100): The repository features an explicit monorepo layout with 7 self-contained reference servers under `src/` (4 TypeScript, 3 Python) with explicit package boundaries, strict TypeScript settings, Zod schemas, and a detailed CLAUDE.md file guiding navigation. Minor gaps include package-level dependencies needing manual `cd` across packages for local development and lack of a central root-level test runner script for all servers combined.
Verification Surface
85Trustworthy, runnable test suites and CI workflows cover all packages across both language stacks.
Verification and checks are robustly implemented for both TypeScript and Python servers in the monorepo, supported by Vitest, Pytest, Pyright, Ruff, and explicit GitHub Actions workflows with dynamic package detection. Every sub-package contains its own tests and configuration files, clearing the Solid band.
Agent Safety
85Strong secret hygiene and security policy with clean boundaries, though explicit agent tool restrictions are minimal.
The repository exhibits exemplary secret hygiene with `.gitignore` covering environment files, no committed secrets or environment files, and a valid `SECURITY.md`. It provides clear operational guidelines in `CLAUDE.md`, though explicit agent tool restrictions or sandboxing boundaries are left to the individual reference servers. This comfortably clears the Solid band (70-89) for agent safety.
Context Economy
80Clean monorepo structure with zero generated clutter or committed build artifacts.
The repository manages context effectively as an npm workspaces monorepo under src/, with committedNodeModules=no, committedBuildOutput=no, and robust linguist markers (.gitattributes). While containing multiple languages (TypeScript and Python) across 156 files, signal-to-noise is exceptionally high due to clean separation, strict ignores, and dedicated standalone package structure. This easily clears the 70–89 Solid band.
Machine Orientation
7 checks passed3 problems found
- lowllms.txt present
An llms.txt is the emerging machine-orientation standard — a curated map for LLMs.
Fix: Add an llms.txt pointing at the key docs and entry points.
- lowTopics set
GitHub topics situate the repo's domain and stack for an agent at a glance.
Fix: Add a few GitHub topics describing the domain and stack.
- lowExamples directory
An examples/ directory gives an agent runnable, copyable references for the API.
Fix: Add an examples/ directory with small, runnable usage samples.
- README present — An agent reconstructs what the repo is and how to work in it from the README first.
- Agent instructions file — AGENTS.md / CLAUDE.md is the direct, machine-read channel for entry points and conventions.
- Agent instructions stay lean — A bloated instructions file burns context and measurably hurts more than it helps.
- Repository description set — The one-line description is the fastest orientation signal an agent reads.
- Architecture doc — An ARCHITECTURE doc hands an agent the module map instead of making it infer one.
- README shows usage — A usage/example section tells an agent how the project is actually invoked.
- Contribution conventions are written down — A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.
Reproducible Setup
3 checks passed3 problems found
- mediumRuntime / toolchain pinned
An unpinned runtime makes an agent guess the version a clean environment needs.
Fix: Pin the runtime with .nvmrc / .tool-versions / an engines field / packageManager.
- lowEnv template present
A .env.example tells an agent which configuration keys it must supply to run.
Fix: Ship a .env.example listing every required key with placeholder values.
- lowDev container
A .devcontainer gives an agent a one-command, fully-declared environment.
Fix: Add a .devcontainer so the toolchain is declared, not assumed.
- Lockfile committed — Without a lockfile two clones can resolve different dependency trees — the build isn't reproducible.
- Container or dev-container — A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.
- README documents setup — Explicit install/setup steps are what let an agent go from clone to running.
Code Navigability
2 checks passed3 problems found
- low.editorconfig present
An .editorconfig keeps whitespace and encoding consistent, so diffs stay legible.
Fix: Add an .editorconfig pinning indentation, charset, and final-newline.
- lowFormatter configured
A formatter config (Prettier/Biome/rustfmt/…) keeps style uniform across the tree.
Fix: Add a formatter (Prettier, Biome, rustfmt, …) and commit its config.
- lowTyped public API
A declared `types` entry gives an agent typed signatures to anchor an edit on.
Fix: Ship type declarations and point package.json `types`/`typings` at them.
- Conventional source layout — A recognised src/ · lib/ · app/ layout lets an agent localise code without spelunking.
- TypeScript strict mode on — Strict typing gives an agent typed signatures to anchor an edit on, not guesses.
Verification Surface
3 checks passed4 problems found
- mediumTest command defined
A `test` script is the documented, discoverable way to run the suite.
Fix: Add a `test` script (package.json / Makefile / Taskfile) that runs the suite.
- lowLint command defined
A linter an agent can run catches a class of mistakes before they ship.
Fix: Add a `lint` script and a linter config.
- lowTask runner present
A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.
Fix: Add a Makefile / Taskfile / justfile collecting the common commands.
- lowTypecheck command
A typecheck script lets an agent catch type errors before they ship.
Fix: Add a `typecheck` script (e.g. `tsc --noEmit`).
- Tests present — Runnable tests are the ground truth an agent checks its own edits against.
- CI configured — Readable CI is the feedback loop an agent reads to know what 'green' means here.
- Build command — A documented build command is the discoverable way for an agent to produce artifacts.
Agent Safety
7 checks passed4 problems found
- mediumPolicy names the threat model
A scanning agent aims at what the repo says it is defending, and where untrusted input crosses in.
Fix: Describe the threat model and trust boundaries in SECURITY.md — what is attacker-controlled, and where it reaches trusted code.
- mediumPolicy scopes what counts as a finding
With no reportable-finding bar and no out-of-scope list, an automated scan returns noise nobody triages.
Fix: State in SECURITY.md what counts as a reportable finding, and what is out of scope or accepted risk.
- lowCODEOWNERS present
CODEOWNERS marks the 'don't touch without review' zones an agent should respect.
Fix: Add a CODEOWNERS file marking the sensitive paths.
- lowPolicy gives severity context
Severity judged against this system beats a generic rating an agent had to guess at.
Fix: Say in SECURITY.md how severity is judged here — what makes a finding critical for this system.
- No committed .env — A tracked real .env hands secrets to anything — including an agent — that reads the repo.
- No exposed secrets — Secret-shaped literals in tracked files are a live credential leak.
- .gitignore covers env files — An ignore rule for .env is what keeps the next careless commit from leaking secrets.
- Automated dependency updates — Dependabot / Renovate keeps dependencies patched without a human in the loop.
- .gitignore present — A .gitignore is the first guard against an agent committing secrets or build junk.
- Security policy — A SECURITY.md is where an autonomous security agent reads this repo's rules before acting on it.
- License makes the code reusable — Without a license an agent cannot safely copy, redistribute, or vendor any of this code.
Context Economy
4 checks passed0 problems found
- Dependencies not vendored in — A committed node_modules / vendor tree drowns the real signal an agent needs.
- Build output not committed — Generated dist/ · build/ output is noise an agent has to read past.
- Generated / vendored files marked — A .gitattributes linguist marker tells tools (and agents) what to skip.
- No oversized source file — A single file in the hundreds of KB blows past an agent's effective context window.
How ready the repo is for a human newcomer to understand, set up, and contribute.
86 / 10016 of 32 checks passed across 6 categories.
First Impression
85Clear purpose, scope, and runnable client examples make onboarding straightforward from the first screen.
The README explicitly defines the repository's purpose as a collection of official Model Context Protocol (MCP) reference implementations, detailing who it's for, listing specific reference servers, and providing concrete setup and client configuration examples (e.g., Claude Desktop JSON snippets). It clears the Solid band (70–89) by offering immediate onboarding and clear scope, falling short of Exemplary only because topic tags are absent and no top-level demo screenshot/GIF is included.
Getting Running
85Getting running is straightforward thanks to explicit per-package build and run instructions in CLAUDE.md and the README.
The repository provides clear instructions in CLAUDE.md and README.md for both TypeScript and Python reference servers, including uv and npm commands, though it lacks an explicit root env.example or devcontainer. This lands firmly in the Solid band (70–89).
Finding Your Way
90Crystal clear architecture and navigation maps make this repository exceptionally easy to traverse.
The repository provides an exceptional developer orientation via a detailed README, comprehensive CLAUDE.md architecture guide, and clear monorepo workspace layout under `src/`. Module boundaries are distinct, separating TypeScript and Python reference implementations with consistent file naming and strict typing. This easily clears the Solid band and approaches Exemplary standards.
Path to Contribute
82Solid contribution guidelines and setup instructions, with only minor gaps like issue templates.
The repository features a clear CONTRIBUTING.md guide, a comprehensive project navigation file (CLAUDE.md), and a pull request template, ensuring a solid route to contribution. While issue templates are absent, the existing documentation and build scripts clearly outline setup and testing for both TypeScript and Python workspaces. This clears the Solid band (70-89).
Signs of Life
85Active, well-maintained repository with robust multi-language CI workflows and recent activity.
The repository exhibits clear signs of active maintenance with recent commits (last pushed Sept 2026), 5 distinct GitHub Actions workflows verifying both TypeScript and Python packages, lockfiles (package-lock.json and uv.lock), and structured contribution and release guidelines. It clears the Solid (70–89) band easily due to comprehensive CI pipelines and active maintenance signals.
Open Door
90Safely open with a clear license, code of conduct, and visible community channels.
The repository features a clearly stated license (Apache-2.0 / MIT hybrid transition detailed in LICENSE), a comprehensive Code of Conduct (CODE_OF_CONDUCT.md with reporting instructions), and clear avenues to ask for help and contribute (CONTRIBUTING.md and GitHub Discussions links). These complete, machine-verifiable elements comfortably clear the Solid band.
First Impression
3 checks passed3 problems found
- lowTopics set
Topics situate the project's domain at a glance and help a newcomer find it.
Fix: Add a few GitHub topics describing the domain and stack.
- lowStatus badges
Build/version badges signal at a glance that the project is alive and healthy.
Fix: Add a few status badges (CI, version, license) near the top of the README.
- lowExamples to learn from
An examples/ directory gives a newcomer something concrete to run and adapt.
Fix: Add an examples/ directory with small, runnable samples.
- README present — The README is the first screen — with none, a newcomer has nothing to land on.
- Repository description set — The one-line description sets expectations before a newcomer even opens the README.
- README shows what it does — A usage/example section lets a newcomer see the tool in action before committing.
Getting Running
3 checks passed3 problems found
- mediumPrerequisite versions pinned
Unpinned prerequisites are the classic 'works on my machine' first-run failure.
Fix: Pin the required versions with .nvmrc / .tool-versions / an engines field.
- lowEnv template present
A .env.example shows a newcomer exactly which settings they must fill in to run it.
Fix: Ship a .env.example listing every required key with placeholder values.
- lowOne-click dev container
A .devcontainer lets a newcomer start in a cloud IDE with zero local setup.
Fix: Add a .devcontainer for a one-click, batteries-included environment.
- Lockfile committed — Without a lockfile a newcomer's install resolves differently and hits errors the docs don't mention.
- One-command environment — A Dockerfile / compose / devcontainer turns a fiddly setup into one command.
- README documents setup — Explicit install steps are the difference between a 5-minute start and giving up.
Finding Your Way
3 checks passed2 problems found
- low.editorconfig present
Consistent indentation/encoding keeps the code readable and diffs clean for newcomers.
Fix: Add an .editorconfig pinning indentation, charset, and final-newline.
- lowFormatter configured
An auto-formatter means a newcomer never guesses the house style.
Fix: Add a formatter (Prettier, Biome, rustfmt, …) and commit its config.
- Conventional source layout — A familiar src/ · lib/ · app/ layout lets a newcomer guess where things live.
- Architecture / overview doc — An overview hands a newcomer the map instead of making them reconstruct it.
- No oversized source file — A single thousand-line file is a wall a newcomer bounces off.
Path to Contribute
1 check passed5 problems found
- lowIssue templates
Issue templates show a newcomer how to file something useful — and that contributions are welcome.
Fix: Add issue templates under .github/ISSUE_TEMPLATE.
- lowPull-request template
A PR template tells a first-time contributor what a good change includes.
Fix: Add a PULL_REQUEST_TEMPLATE.md.
- lowTest command defined
A documented test command lets a contributor check their change before opening a PR.
Fix: Add a `test` script that runs the suite.
- lowLint command
A linter lets a first-time contributor catch style issues before review.
Fix: Add a `lint` script and a linter config.
- lowTask runner
A Makefile / Taskfile gives a contributor a single index of the project's commands.
Fix: Add a Makefile / Taskfile collecting the common dev commands.
- CONTRIBUTING guide — A CONTRIBUTING guide is the difference between a guessed and a guided first PR.
Signs of Life
3 checks passed2 problems found
- lowChangelog
A maintained CHANGELOG shows a newcomer the project ships and records its changes.
Fix: Keep a CHANGELOG.md (e.g. the Keep a Changelog format).
- lowFunding configured
A FUNDING config signals an invested, sponsored project — not a one-off dump.
Fix: Add a .github/FUNDING.yml if the project accepts sponsorship.
- Tests present — A test suite signals a project that's cared for, not abandoned.
- CI configured — Green CI on every change tells a newcomer the project is actively kept working.
- Automated dependency updates — Dependabot / Renovate activity is a visible heartbeat of ongoing maintenance.
Open Door
3 checks passed1 problem found
- lowLicense is a standard one
A non-standard or custom license is a legal question mark a newcomer won't resolve.
Fix: Use a recognised OSI license so reuse terms are unambiguous.
- License present — With no license the project isn't legally reusable — the door is shut however friendly the README.
- Code of conduct — A code of conduct states the social ground rules that make it safe to step in.
- Security policy — A SECURITY.md tells a newcomer how to report a problem responsibly.
Where the grip slips
- lowReproducible Setup+4 pts if fixed
Missing unified root task runner or container setup
No unified top-level lockfile pin or single-command bootstrap for mixed TypeScript and Python subpackages in src/ without manually cd'ing into each directory.
Fix: Provide a top-level Makefile or task runner script that bootstraps and tests both Node and Python subpackages with a single command.
- lowVerification Surface+3 pts if fixed
Lack of unified root-level test runner
No root-level unified test script or task runner to run all tests across all language ecosystems simultaneously in a single command.
Fix: Add root-level test scripts or a task runner configuration to orchestrate TS and Python test suites together.
- lowAgent Safety+2 pts if fixed
Missing explicit agent safety boundaries in CLAUDE.md
No explicit agent instruction boundaries or safety flags are provided in `CLAUDE.md` to prevent autonomous agents from running destructive git commands or modifying critical release files.
Fix: Add a dedicated safety section to CLAUDE.md outlining forbidden agent actions (e.g., publishing packages, force-pushing, modifying lockfiles manually).
- lowCode Navigability+2 pts if fixed
Missing unified root test command for monorepo workspaces
Root package.json only builds workspaces and lacks a unified `test` script across all TypeScript and Python workspaces.
Fix: Add root-level test and check scripts that iterate across workspaces or invoke test runners per package.
- lowMachine Orientation
Missing repository topics
Topics array in repository metadata is empty, which mildly reduces discoverability via the GitHub API.
Fix: Add descriptive repository topics (e.g., model-context-protocol, mcp, mcp-servers, typescript, python) in repository settings.
Show your score
[](https://latch.fyi/modelcontextprotocol/servers)Share this analysis
https://latch.fyi/modelcontextprotocol/serversFixed some issues? Re-analyze to measure your progress →
Copy the whole report
Grab the entire verdict in one go — a Markdown block for a README or an issue, plain text, or a prompt you can paste straight into an LLM.