Obra Cto

com.get-obraPublished by get-obra.comv0.3.0Updated Oct 24, 2026

Local-first MCP that scores your codebase's build readiness. Your code never leaves your machine.

Overview

AI-generated overview

A local-first MCP server that scans a codebase, runs its tests and produces a scored build-readiness report with a ranked risk register.

What you can do
Scan a project for mechanical signals and select high-signal files for a stack-tuned code review checklist, including a design red-team pass on the architecture and a backend-as-a-service lens for Supabase and Firebase projects. Check locked dependencies against the OSV vulnerability database. Run the project's test suite and parse pass and fail counts. Produce an Obra CTO Score out of 100 across security, product reality, robustness, architecture, maintainability and deploy readiness, with every finding graded by evidence strength and a Top Risks register.
When to use it
Useful when you want a technical-diligence style read on a project before a funding or serious review conversation, or a repeatable readiness score calibrated to prototype, MVP or growth stage. Also handy for surfacing security and architecture gaps and for pairing with the Obra CFO server, which reads its report as technical evidence.
Requirements
Runs as a local process via npx from the npm package obra-cto, or from a cloned source build with Node.js. No account, API key, environment variable or header is declared. Network access is needed only for the dependency check, which contacts the OSV vulnerability database.
Before you install
The test runner executes the project's own test code on your machine, so only point it at projects you trust; the README says the assistant asks before running it. The dependency check sends package names and versions to the OSV database, though not source code. The README states the server is not a linter or a full security scanner, so treat its score as readiness guidance rather than an audit.

Installation

In SourceWeft

  1. Open Obra Cto in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

Obra CTO

A local-first MCP server that scores your codebase's Build Readiness. You install it in your own Claude. Your Claude reads your code on your machine and runs your tests there. Nothing is uploaded.

This is the free preview of Obra's role lineup, and it stays free and local. The CTO reads your code and tells you what an investor's technical diligence would find: real security holes, weak design decisions, and the gaps that stop a serious review. The rest of the team (the Obra CFO for funding-ready materials, and more) lives in the Build with Obra community.

The Obra founders' toolkit

Two free, local, open-source MCPs built to work as a pair:

  • Obra CTO (this one): is it built? Scores your codebase and surfaces what a technical diligence would flag. GitHub · npm
  • Obra CFO: is it fundable? Runs the investment committee on your pitch and turns your verified build into a funding case. GitHub · npm

Run the CTO first. The CFO reads its report as grade-A technical evidence. The method, the deep versions, and Obra in beta live in Build with Obra.

Why local-first

A tool that reads your code should not ship your code somewhere. Your source never leaves your machine. This server makes exactly one kind of network call, and only when you run the dependency check: it sends your package names and versions to the OSV vulnerability database, never a line of your code (you can see the single call in src/deps.ts). Everything else is local: it returns counts, presence flags, a redacted secrets scan, and a score. You can read every line of this server before you run it, which is the point of keeping it open.

What you get

The Obra CTO Score, out of 100, calibrated to your stage (prototype, MVP, or growth), across six dimensions:

DimensionWeight
Security25
Product reality (what is actually built)20
Robustness15
Architecture15
Maintainability15
Deploy readiness10

Every finding carries an evidence grade: A verified, B multiple sources, C partial or inferred, D claim only, E speculation. The score is built from grade A and C evidence, what is true in your code, not what a deck says. When the CTO runs your tests and they pass, reliability becomes grade A. A deck-scorer can never earn that.

What a run looks like

Point it at a real project and you get a scored report with a ranked risk register. Here is a run on a scrappy Supabase app (anonymized):

# Obra CTO Score: financeapp## 46 / 100 · Not yet readyAssessed as: mobile (react-native, expo)  |  Backend: supabase
| Dimension        | Score | Evidence ||------------------|-------|----------|| Security         | 6/25  | A || Product reality  | 20/20 | A || Robustness       | 3/15  | A || Architecture     | 9/15  | A || Maintainability  | 6/15  | A || Deploy readiness | 2/10  | C |
## Top Risks- [critical] RLS policies defined but never enabled; data may be open to any authenticated user    Fix: enable row level security on every table, then verify a second user cannot read your rows.- [high] Access control gap: a privileged action checks only that the user is logged in, not that they own the resource- [medium] No tests found

On a well-built app it scores high and credits the good engineering. It is calibrated, not a fear machine.

Tools

  • scan_project reads the project and returns mechanical signals.
  • check_dependencies checks your locked dependencies against the OSV vulnerability database. Only package names and versions leave your machine, never your code.
  • run_tests runs your test suite (this executes code, so your Claude asks first) and parses the pass and fail counts.
  • prepare_code_review selects your highest-signal files (schema and policy files, entry points, security-relevant code) and hands them to your Claude with a checklist tuned to your stack, including a Backend-as-a-Service lens (Supabase, Firebase) and a design red-team that critiques the architecture, not just the code.
  • score_build_readiness produces the Obra CTO Score with a Top Risks register.

A normal run is: scan, check dependencies, run tests, prepare the code review, then score.

Install

Add it to your Claude MCP config (Claude Desktop or Claude Code):

json
{  "mcpServers": {    "obra-cto": {      "command": "npx",      "args": ["-y", "obra-cto"]    }  }}

Then ask your Claude: "Score this project's build readiness with Obra CTO."

Prefer to run from source? Clone the repo, run npm install && npm run build, and point the config at node /absolute/path/to/obra-cto/dist/index.js.

What this is not

Not a linter, not a security scanner, not a replacement for your own Claude reading the code. It is technical-diligence readiness inside funding readiness: the question an investor's CTO would ask, answered from your real code.

What's next

The Obra CTO is the free preview. To go further:

  • The Method: the full playbook for shipping production software with AI, the disciplines that make code score like the example above, each lesson with a paste-in prompt or tool you can use today.
  • The rest of the team: the Obra CFO for funding-ready materials, and each new role as it ships.
  • Obra itself, in beta: the AI employee that runs your back office. Members go first.

See the whole toolset and where it is going at https://get-obra.com/build

The full method and the community live in Build with Obra: https://www.skool.com/build-with-obra-5361/about

License

Apache-2.0.

Source: README.md at commit 9fbe5d4

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v0.3.0LatestSep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts