Skip to main content
Glama
wlsdks

ontology-atlas

by wlsdks
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

analyze_repo_structure

Read-only

Analyze a code repository to extract evidence-backed ontology candidates—projects, domains, capabilities, and elements—before any vault write.

Instructions

R16 (autonomous ingest base) — analyze a code repository and propose ontology node candidates. side effect 0 (vault frontmatter NOT modified). Returns deterministic candidates the agent must turn into an evidence-backed proposal and move through the construction lifecycle before any exact batch-writer rows are released. Repository structure is implementation evidence, not automatic business meaning: extractionContract and proposedBusinessOntology make that uncertainty explicit. Detects:

  • package.json name → project candidate

  • README.md first H1 → project title fallback

  • README.md H2 sections (skipping generic "Usage"/"Installation"/etc) → domain candidates

  • src/features|entities|widgets|views/* (FSD) → capability/element candidates

  • src/* depth-1 folders (generic) → capability candidates + index entry → element

  • apps/* and packages/* members with package.json → implementation element candidates

  • README.rst + bounded static setup.py → Python project/package evidence without execution

  • mixed current and future/negated/deprecated README prose → exact current candidate excerpt plus bounded line-scoped reviewRequiredEvidence; review units stay visible but cannot support a proposal claim

  • selected safe README sections share the existing 1,200-character budget deterministically; no document, heading, or excerpt cap grows

  • root Python packages plus at most 12 import-connected implementation boundaries → direct modules plus up to 2 exact security/policy/risk file anchors; unused files are not mirrored and no capability is inferred from imports

  • bounded root Cargo package or repo-contained literal direct workspace members → typed feature declaration + literal cfg/cfg_attr source provenance; predicates are not evaluated and no runtime/import/semantic dependency is inferred

  • a complete proposal may select at most 4 additional exact TypeScript, JavaScript, Python, or Rust file endpoints already observed by infer_imports for distinct navigation roles; exact dependency direction is validated and these files never become automatic candidates

  • an element proposal may keep an ordinary citation and append reviewed navigation:primary|supporting|test:<path>#<symbol> evidence strings (limits 1/1/3); the server verifies only those named current files, renders human-readable Evidence bullets, and rejects missing, ambiguous, unsafe, or task-inferred coordinates without treating them as behavior proof

Optionally pass a complete proposal to validate project/domain/capability/element definitions, typed relations, citations, risk controls, domain placement, implementation paths, confidence, and typed competency answers with resolvable concept/relation/evidence/path witnesses. Partial or visible-gap answers remain warnings instead of disappearing behind findings 0. A unqualified-project-exclusion warning is an exact human-acceptance gap, while an evidence-limit exclusion remains an error. Source-hidden review may leave exact source-body detail partial; source-aware citation verification decides support before evidence provenance can pass. A mandatory non-gap warning blocks the first review before qualification begins. For a bounded first pass, freeze claim id, statement, and proposalRefs before isolated source-hidden and source-aware lanes run in parallel; separately audit material Definition, Includes, Excludes, and Uncertainty assertions even when several claims share one proposal ref. Join sealed receipts without mutation before human acceptance. A passing validation first returns a deterministic non-writing reviewPlan, planDigest, sourceDigest, and eight-phase construction lifecycle. An independent evaluator must measure the approved competency questions and source-hidden task, then a human may declare acceptance bound to that exact plan digest/revision and every visible gap. Pass the resulting constructionQualification:v1 packet as qualification; only a current, admissible packet releases the exact reviewed rows as writePlan. The lifecycle also reports a shadow-only admission tier; self_qualified is an observation, not a write permission. Declared approval provenance is not identity authentication. Do not call write tools unless proposalValidation.canWrite is true and a writePlan is present; write every concept row successfully before writing relations.

Use this once when a user asks "이 codebase 분석해줘" / "bootstrap the ontology". Single source of truth preserved — only the user (via your subsequent add_concept calls) writes to the vault.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ignoreNoExtra folder names to skip (added to defaults: node_modules, .git, dist, build, …).
maxDepthNoNon-negative integer folder walk depth (default 2, max 10). Higher → more elements.
proposalNoOptional business ontology proposal to validate against repository evidence before any write call. Python proposals may select at most 4 exact observed import endpoints beyond the analyzer candidates.
rootPathNoRepository root to analyze. Defaults to the MCP server cwd.
qualificationNoOptional independent evaluation and declared human acceptance bound to the exact planDigest, planRevision, and sourceDigest returned for this proposal. Omit it on the first review call.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainsYes
projectNo
skippedYes
elementsYes
rootPathYes
frameworkYes
meaningGateYes
capabilitiesYes
semanticEvidenceYes
extractionContractYes
proposalValidationYes
suggestedRelationsYes
configurationEvidenceYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.0

TDQS

A4.1/5.0
Behavior5/5

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

Discloses side-effect-free behavior ('side effect 0 (vault frontmatter NOT modified)') and deterministic output semantics. It also reveals server-side validation behavior (verifies only named current files, rejects missing/ambiguous/unsafe coordinates) and the requirement to convert candidates into an evidence-backed proposal before any write. These traits go beyond the readOnlyHint/destructiveHint annotations and add significant operational context.

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

Conciseness1/5

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

The description is an enormous, unstructured wall of text lacking paragraph breaks or coherent organization. It mixes the tool's core purpose, detailed detection heuristics, validation policy, and agent workflow instructions into one dense block. Many sentences are tangential (e.g., about 'declared approval provenance' and 'identity authentication'), making it poorly scannable and not appropriately sized for an MCP description.

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?

For a tool of this complexity, the description covers the key aspects: what the tool does, the optional inputs (proposal, qualification), the return values (deterministic candidates, reviewPlan, planDigest, sourceDigest), and the critical constraint that writes must not occur until a writePlan is present. No obvious information needed for correct invocation is missing, though the verbosity dilutes it.

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

Parameters4/5

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

The description adds meaning for the complex parameters by explaining that a 'proposal' can be passed to validate definitions and that a 'constructionQualification:v1' packet is passed as 'qualification'. It also explains the effect of proposal validation. Since schema coverage is 100%, the baseline is 3; the added guidance for these two parameters lifts it to 4.

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

Purpose4/5

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

The description opens with a clear action: 'analyze a code repository and propose ontology node candidates.' It also states the output is 'deterministic candidates' and clarifies the tool has no side effect on vault frontmatter. It does not explicitly contrast with sibling tools like infer_imports or inspect_architecture, but the core purpose is unambiguous.

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?

Provides an explicit trigger: 'Use this once when a user asks "이 codebase 분석해줘" / "bootstrap the ontology".' It also gives a strong negative condition: 'Do not call write tools unless proposalValidation.canWrite is true and a writePlan is present.' This clearly tells the agent when to invoke the tool and what to avoid.

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