oss-analyzer
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| oss_lsp_referencesC | 심볼 참조 위치 전체 (LSP). 줄·열은 1부터. 결과는 L1 근거로 기록됨. |
| oss_lsp_definitionC | 심볼 정의 위치 (LSP). 결과는 L1 근거로 기록됨. |
| oss_lsp_call_hierarchyB | 호출 계층 (LSP callHierarchy). direction: incoming(누가 부르나) / outgoing(무엇을 부르나). L1 근거로 기록됨. Args: line, column: 함수 이름 위치 (1부터) |
| oss_dataflow_buildB | 데이터 흐름용 CPG 를 만든다 (Joern). 처음 한 번 오래 걸리고 이후엔 캐시. language 생략 시 주 언어. |
| oss_dataflow_queryA | 값 흐름(L2): 소스(함수 정의 줄 → 매개변수, 또는 호출 줄 → 인자)에서 sink(호출 이름 정규식)까지 흐르는지. Args: queries: [{"path": "...", "line": 91, "sink": "select.|insert.", "max_flows": 20}] 결과의 evidence_id 는 L2 근거. 흐름 0건은 '흐름 없음'의 증명이 아님 (limitations 참고). |
| oss_graph_queryC | 구조 지도 읽기 전용 Cypher 질의 (codebase-memory-mcp). 이름 기반 해석이라 L0. |
| oss_unknown_recordB | 확정하지 못한 것을 미확인으로 기록. 같은 질문·범위는 중복 생성되지 않음. Args: domain: 예) dataflow / dynamic-dispatch / config / entrypoint / external-dependency severity: low / medium / high / critical required_level: 해결에 필요한 최소 근거 등급 (L0~L3) recommended_probes: [{"operation": "...", "rationale": "..."}] |
| oss_unknown_updateB | 미확인 갱신·해결. 해결(resolution.disposition=verified)은 required_level 이상 근거가 있어야 함. Args: expected_revision: 마지막으로 읽은 revision (다르면 revision_conflict) resolution: {"disposition": "verified"|"withdrawn"|"out-of-scope", "rationale": "...", "evidence_ids": [...]} |
| oss_unknowns_listC | 미확인 목록 (심각도순, 페이징). |
| oss_evidence_getC | 근거 상세 (제공자·연산·위치·한계). |
| oss_inventory_buildA | 고정 커밋의 전 파일 분류 + 구조 지도 인덱싱 + 심볼 전수 배정 + 단위 분할 + 진입점 수집. 엔진이 못 본 곳(파싱 실패·규칙팩 없는 프레임워크·동적 경로·바이너리)은 미확인으로 자동 등록. Args: project_id: oss_repo_open 이 돌려준 id rebuild: 다시 만들기 (진행 중·완료 단위가 있으면 거부) |
| oss_capabilitiesC | 언어별로 쓸 수 있는 엔진과 단위 상한 등급. |
| oss_units_listC | 단위 목록 (status: pending / in_progress / done). |
| oss_file_classifyB | 규칙으로 분류되지 않은(unclassified) 파일 등을 직접 분류. 사유 필수. Args: category: doc / generated / vendored / secret / binary / asset / code / test reason: 이렇게 분류한 이유 |
| oss_unit_nextB | 다음 분석 단위를 임대한다. 이미 임대한 단위가 있으면 그것을 돌려줌. 병렬 분석 시 agent 를 서로 다르게. Args: agent: 분석하는 에이전트 id (서브에이전트마다 다르게) kind: code / asset / test 중 하나로 제한 (선택) |
| oss_unit_contextB | 단위 코드(줄 번호 포함)·심볼 목록·호출 간선(L0 근거 id 포함). 코드가 크면 next_offset 으로 이어 읽기. offset 은 '단위 안의 줄 순번'(next_line 이 파일:줄). 심볼·간선은 첫 페이지에만. 신뢰도 0.5 미만 간선은 all_calls=true 일 때만. |
| oss_unit_renewC | 임대 연장 (도구 호출마다 자동 연장되지만, 오래 생각만 할 때 명시적으로). |
| oss_finding_recordB | 결론을 근거와 함께 기록. 근거 위치는 고정 커밋 기준으로 검증되고, 틀리면 거부된다. Args: text: 결론 문장 (무엇을 어떻게 하는지) evidence: [{"evidence_id": "ev_..."}] (도구가 만든 근거) 또는 [{"path", "start_line", "end_line"}] (직접 읽은 위치) symbol_ids: 이 결론이 설명하는 심볼 id 들 (oss_unit_context 의 symbols[].id) — 검토 완료로 표시됨 severity: info / important / critical (important 이상은 독립 검토 필요) |
| oss_symbols_markC | 결론으로 남길 만한 동작이 없는 심볼(단순 getter·DTO 필드 묶음 등)을 사유와 함께 검토 완료 처리. |
| oss_unit_completeC | 단위 완료. 검토 안 된 심볼이 있으면 거부(누락 목록 반환). 목표 등급 미달이면 미확인 자동 생성. |
| oss_claim_reviewB | important/critical 결론의 독립 검토. 작성자와 다른 reviewer id 여야 함. rejected 면 미확인 생성. Args: verdict: confirmed / rejected |
| oss_claim_withdrawB | 내가 쓴 결론 철회 (틀렸거나 문장을 고쳐 다시 낸 옛 판본). 완료된 단위도 가능하며 단위 등급을 다시 계산. |
| oss_claims_pendingC | 독립 검토를 기다리는 결론 목록 (critical 먼저). |
| oss_report_coverageC | 2축(파일·심볼) 커버리지와 완료 조건(gates). complete=true 여야 '전수 분석 완료'. |
| oss_report_featuresD | 기능 카탈로그 (진입점: http / http-mount / cli / main / scheduler / listener / background-task). |
| oss_report_exportC | 리포트를 Markdown + JSON 으로 내보낸다. 경로를 돌려줌. |
| oss_doctorA | 엔진 설치 여부·버전과 설치 안내. languages 를 주면 그 언어의 LSP 만 점검. Args: languages: 점검할 언어 목록 (예: ["rust", "python"]). 생략 시 지원 언어 전체. |
| oss_repo_openA | 분석할 저장소를 열고 커밋을 고정한다. 분석 전용 clone 을 만들어 원본 작업 트리와 분리. Args: source: 로컬 경로 또는 git URL ref: 고정할 브랜치·태그·커밋 (생략 시 HEAD) name: 프로젝트 이름 (생략 시 저장소 이름). 실제 id 는 -<커밋 앞 8자리> |
| oss_repo_listC | 열어 둔 프로젝트 목록. |
| oss_repo_statusC | 프로젝트 메타데이터(원본·커밋·인벤토리 시각·엔진 능력). |
| oss_repo_closeB | 언어 서버와 DB 연결을 닫는다. 원장·clone 은 지우지 않음 (다음에 이어서 분석 가능). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 31 tools
Most tools have clearly distinct targets and actions: repo lifecycle, LSP operations, dataflow build/query, unit leasing, findings, claims, unknowns, and reports are all separable. A few pairs could be confused, such as oss_unit_complete vs oss_symbols_mark (both mark work as reviewed) and oss_unknown_update vs oss_claim_withdraw (both resolve records), but the descriptions differentiate them.
A strong oss_<resource>_<verb> pattern is used throughout (oss_repo_open, oss_unit_next, oss_finding_record, oss_claim_review). Minor deviations exist: noun-only tools like oss_capabilities and oss_doctor, plus singular/plural oscillation between oss_unknown_record and oss_unknowns_list, and oss_unit_next vs oss_units_list.
31 tools is heavy and sits at the upper boundary where the surface starts to feel fragmented across evidence, claims, unknowns, and units. The multi-stage audit workflow justifies much of it, but several groups (claim review/withdraw/pending, unknown record/update/list) could be consolidated without losing capability.
The surface covers the full lifecycle: repo open/list/status/close, inventory build, unit leasing and context, symbol marking, finding recording, independent review, unknown tracking, coverage/features/export reports, plus LSP and dataflow engines and a doctor/capabilities check. There are no obvious dead ends for the stated deep-audit purpose.