How do I use Obra CTO?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Obra CTO score this project's build readiness" 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.

Obra CTO

by lilycip

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

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.

Related MCP server: graphward

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:

Dimension	Weight
Security	25
Product reality (what is actually built)	20
Robustness	15
Architecture	15
Maintainability	15
Deploy readiness	10

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 ready
Assessed 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):

{
  "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.

Available Tools

5 tools

check_dependenciesCheck dependencies for known CVEsA

Read-only

Query OSV.dev for known vulnerabilities in the project's locked dependencies, using exact versions from package-lock.json. Only package names and versions are sent, never your code. Real, current CVE data. Feed any findings into your security assessment.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Project root. Defaults to the current working directory.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds specific behavioral traits: queries real, current CVE data, and sends only package names/versions (privacy guarantee). No contradictions with annotations.

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?

The description is concise (three sentences) with front-loaded action verb 'Query'. Every sentence adds value: purpose, method, privacy, data freshness, and usage guidance. No redundant information.

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

Completeness5/5

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

Given the tool's simplicity (one optional parameter, no output schema), the description fully covers what the agent needs: what it does, how it works, privacy, and how to use results. No gaps.

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?

With 100% schema description coverage, the description does not add further semantics for the single parameter 'path'. The schema already documents its purpose and default behavior, so baseline 3 is appropriate.

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 action ('Query OSV.dev'), the resource ('locked dependencies'), and the specificity ('using exact versions from package-lock.json'). It distinguishes itself from sibling tools like 'scan_project' by focusing on CVE vulnerabilities in locked dependencies.

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 implies when to use (to check for CVEs in lockfile) and provides guidance on privacy ('Only package names and versions are sent'). It suggests using results in security assessment. However, it lacks explicit when-not-to-use or direct alternatives.

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

prepare_code_reviewPrepare code reviewA

Select the highest-signal files (security-relevant paths, entry points, large files) and return their contents on this machine, with a review checklist. YOU, the host model, then read them and produce a structured security and architecture assessment, which you pass to score_build_readiness as qualitative. This is what upgrades those dimensions from inferred (grade C) to verified (grade A). Files stay local.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Project root. Defaults to the current working directory.
`max_files`	No	Maximum files to return (default 12).

TDQS

A3.8/5.0

Behavior3/5

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

Discloses that files stay local and selection criteria, but no annotations are present. Lacks details on side effects, idempotency, or whether any modifications occur. Basic transparency but not comprehensive.

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?

Three sentences that efficiently convey purpose, selection logic, and workflow. Front-loaded with action. Minor redundancy could be trimmed, but overall well-structured.

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?

Explains the tool's role in upgrading dimensions from inferred to verified, but lacks detail on the output format (file contents and checklist). No output schema, so description should compensate. Adequate but not complete.

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% with descriptions for path and max_files. The description does not add extra semantic information beyond the schema, meeting the baseline but not exceeding it.

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?

Clearly states it selects highest-signal files (security-relevant, entry points, large files) and returns their contents with a review checklist. Distinguishes from sibling tools like scan_project and score_build_readiness by its specific role in the pipeline.

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?

Provides clear context: use this to gather files for review, then the model produces an assessment passed to score_build_readiness. Implies when-not by describing the workflow, though no explicit exclusions.

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

run_testsRun testsA

Run the project's test suite on this machine and parse pass/fail counts. This EXECUTES the project's own test command (for example npm test, which runs whatever that script defines), so only approve it for a project you trust to run. Your host asks before it runs. A green suite is the strongest grade-A reliability evidence the Obra CTO Score can use. Pass the result numbers to score_build_readiness.

ParametersJSON Schema

Name	Required	Description
`path`	No	Project root. Defaults to the current working directory.
`command`	No	Override the test command (e.g. "pytest -q"). Defaults to the detected command.
`acknowledge_risk`	No	Only relevant if the malware tripwire flagged this repo as dangerous. Running the test command would execute the flagged code. Set true ONLY after you have inspected the findings and are running in a throwaway sandbox with no keys or logins.

TDQS

A4.7/5.0

Behavior5/5

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

Discloses that the tool executes the project's own test command, which carries risk. Explains that the host asks before execution. Annotations set readOnlyHint=false, which is consistent, but the description adds important context about trust and sandboxing that goes beyond annotations.

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?

Four sentences, each adding value. Front-loaded with the core action and parsing behavior. No redundant or filler content.

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

Completeness5/5

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

Given the tool's complexity (executes commands, parses output, security implications) and absence of an output schema, the description is complete. It explains the return value (pass/fail counts) and its intended downstream use, leaving no significant gaps.

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% with detailed parameter descriptions. The description does not add new parameter meaning beyond the schema but integrates parameters into the narrative. Baseline of 3 is appropriate as schema fully documents parameters.

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 runs the test suite and parses pass/fail counts. It distinguishes itself from siblings like score_build_readiness by stating the output should be passed to that tool, and from others like scan_project which are unrelated.

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

Usage Guidelines5/5

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

Explicitly says when to use (for reliability evidence) and when not (only approve for trusted projects). Advises on risk acknowledgment and mentions the host asks before running. Directs to pass results to score_build_readiness, providing clear usage context.

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

scan_projectScan projectA

Read a local project and return mechanical Build Readiness signals: file and line counts, languages, test files, CI config, lockfile, docs, and a redacted scan for hardcoded secrets. Returns signals only, never your source. Run this first.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Absolute path to the project root. Defaults to the current working directory.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full weight. It discloses the read-only nature ('never your source') and safety features (redacted secrets scan). No contradictions or undisclosed side effects are apparent.

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 concise sentences: first details output, second clarifies safety and usage order. No wasted words; every sentence adds value.

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

Completeness4/5

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

Given a single optional parameter and no output schema, the description sufficiently explains the return contents. A minor improvement could specify the output format (e.g., JSON object), but current detail is adequate for the tool's simplicity.

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?

Only one parameter 'path' with schema description already covering its purpose and default. The tool description adds no further semantic detail beyond what the schema provides. Baseline 3 due to 100% schema coverage.

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?

Clearly states it reads a local project and returns build readiness signals, listing specific signals like file counts, languages, test files, CI config, lockfile, docs, and secrets scan. Instructs 'Run this first,' distinguishing it from sibling tools that perform different actions.

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?

Explicitly tells the agent to 'Run this first,' establishing it as a preliminary step. Implicitly advises against expecting source code or secrets in the output. No alternatives or exclusions needed due to the tool's single-purpose nature.

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

score_build_readinessScore Build ReadinessA

Produce the Obra CTO Score (0 to 100) with a per-dimension breakdown, evidence grades, and a Top Risks register. Scan runs automatically. If you ran run_tests first, pass its numbers so reliability becomes grade-A evidence.

ParametersJSON Schema

Name	Required	Description
`path`	No	Project root. Defaults to the current working directory.
`stage`	No	Calibrate expectations to your stage: prototype, mvp, or growth. Defaults to a detected guess.
`qualitative`	No	Your structured security and architecture assessment from prepare_code_review. Supplying it upgrades those dimensions to grade A.
`tests_total`	No	Total tests, from a prior run_tests call.
`tests_failed`	No	Failing tests, from a prior run_tests call.
`tests_passed`	No	Passing tests, from a prior run_tests call.
`write_report`	No	Write the report to .obra/ in the project (default true), so the Obra CFO can read it later. Set false to skip writing.

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that the scan runs automatically and writes a report to .obra/ (via write_report parameter). It also explains how supplying test numbers and qualitative assessments affects evidence grading. No destructive actions are implied; the description is sufficiently transparent for a scoring tool.

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?

The main description is two sentences with no waste, clearly stating the output and a critical workflow hint. Parameter descriptions are not repeated in the main text but are part of the schema, keeping the overall description concise and front-loaded.

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

Completeness4/5

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

Given the tool's complexity (7 parameters, nested objects, no output schema), the description provides enough context to use it correctly: it explains the output format (score, breakdown, risks), the automatic scan, and how to leverage prior tool outputs. However, it could be slightly more explicit about the return structure (e.g., JSON object) but overall is complete.

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

Parameters5/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 substantial value beyond the schema: it explains that stage defaults to a detected guess, that qualitative input from prepare_code_review upgrades dimensions to grade A, and that test numbers come from a prior run_tests call. Each parameter's purpose and cross-tool dependency are clarified.

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 produces an Obra CTO Score (0-100) with a per-dimension breakdown, evidence grades, and Top Risks register. This specific verb+resource+output distinguishes it from sibling tools like scan_project and run_tests, which have different purposes.

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 advises the agent to pass test numbers from a prior run_tests call to upgrade reliability to grade-A evidence. It also mentions that the qualitative input can come from prepare_code_review, implying a workflow. However, it does not explicitly state when not to use this tool or list alternatives.

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.

5 tool updatesv0.3.1Jul 29, 2026
- First observedcheck_dependencies
- First observedprepare_code_review
- First observedrun_tests
- First observedscan_project
- First observedscore_build_readiness

Install Server

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

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct, non-overlapping purpose: scanning project signals, running tests, checking dependencies, preparing code review data, and producing the final score. Clear boundaries prevent misselection.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., scan_project, run_tests) using snake_case, making the set predictable and easy to navigate.

Tool Count5/5

Five tools cover the full workflow of build readiness assessment without redundancy. The count is well-scoped for the domain, neither too sparse nor excessive.

Completeness5/5

The tool set covers the entire lifecycle: initial scanning, testing, vulnerability checking, in-depth code review preparation, and final scoring. No obvious gaps for its stated purpose.

Maintenance

ActivityStale

ResponsivenessNo issues

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

mcpcheck B
io.github.joeyough
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Penetration Testing Security
21
Dominion Observatory
com.dominionobservatory
Trust checks for MCP servers: trust scores, tool-drift detection, signed diligence receipts. Free.
Security Observability
2
registry A
com.policylayer
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
Security Developer Tools
521
mcp AOAuth
io.scorecard
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
RAG Systems Monitoring Testing & QA Tools
3

Related MCP Servers

checkyourself
Testing & QA Tools Developer Tools Code Analysis
KyaniteLabs
A
license
A
quality
A
maintenance
Local-first production-readiness MCP server for AI-built apps. It runs read-only checks, produces an evidence-based readiness score, and guides fixes before launch.
Updated 2 days ago (2026-09-06 17:00 UTC)
11
5
Apache 2.0
graphward
Code Analysis Developer Tools Software Architecture
speadskater
A
license
Not graded
quality
B
maintenance
Private, local-first code intelligence MCP server that builds a static graph of repositories and exposes search, architecture, impact analysis, and review tools via MCP.
Updated a month ago (2026-08-10 19:43 UTC)
MIT
local-mcp-toolbox
Developer Tools Shell Access Observability
chriswayneh
A
license
Not graded
quality
A
maintenance
A secure, local-first MCP server for read-only inspection and troubleshooting of development environments, exposing narrow, typed, auditable capabilities for repository inspection, log summarization, Docker review, and security scanning without granting unrestricted machine access.
Updated 19 days ago (2026-08-20 13:15 UTC)
MIT
Repo Test Architect
Code Analysis Testing & QA Tools
RepoAssay
A
license
A
quality
A
maintenance
ocal-first, read-only MCP server that audits repository test architecture across ten language ecosystems. It returns deterministic evidence-backed findings, blockers, rankings, and repository-native test plans without modifying source files.
Updated 2 days ago (2026-09-06 10:27 UTC)
2
19
141
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/lilycip/obra-cto'

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