Skip to main content
Glama
Sign In
Obra CTO

Obra CTO

by lilycip
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Scan project

scan_project

Scans a local project to produce Build Readiness signals including file counts, languages, test files, CI config, lockfile, documentation, and a redacted secrets scan. Returns only metadata, never source code.

Instructions

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "scan_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoAbsolute path to the project root. Defaults to the current working directory.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

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.

Deploy Server

Other Tools