Builds a pinned-commit inventory by classifying files, indexing structure, assigning symbols, splitting units, and collecting entry points; unseen or unparsable areas are flagged unverified.
고정 커밋의 전 파일 분류 + 구조 지도 인덱싱 + 심볼 전수 배정 + 단위 분할 + 진입점 수집. 엔진이 못 본 곳(파싱 실패·규칙팩 없는 프레임워크·동적 경로·바이너리)은 미확인으로 자동 등록.
Args: project_id: oss_repo_open 이 돌려준 id rebuild: 다시 만들기 (진행 중·완료 단위가 있으면 거부)
| Name | Required | Description | Default |
|---|---|---|---|
| rebuild | No | ||
| project_id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose two valuable behaviors: auto-registration of unknowns for anything the engine cannot see, and that rebuild is rejected when units already exist. It says nothing about cost/duration, whether the run is synchronous, what state is created or overwritten, or what happens on partial failure — significant gaps for a heavy pipeline operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the pipeline scope, followed by the failure-mode caveat and a compact Args block. Dense but every sentence contributes; no filler or restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, so the description must fully explain the tool. It covers what is built but not what is returned (counts, job handle, status) or whether the caller must poll a sibling such as oss_repo_status afterwards — a real gap for a multi-stage build.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args block is doing real work: project_id is tied to its source tool (oss_repo_open), and rebuild is given actual semantics (recreate; refused if in-progress or completed units exist). Both parameters gain meaning not present in the bare schema titles. Minor gap: no default value or type hint restated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation and enumerates the five concrete stages it performs (file classification, structural map indexing, symbol assignment, unit splitting, entry-point collection), plus what it does with unparseable input. An agent can tell this is the pipeline that produces the inventory. It does not, however, distinguish itself from build-adjacent siblings such as oss_dataflow_build or oss_file_classify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Prerequisite context is implied rather than stated: project_id is 'the id returned by oss_repo_open', and rebuild is refused when in-progress or completed units exist. There is no explicit statement of when to run this versus the sibling builders, nor any sequencing guidance beyond the id provenance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.