Skip to main content
Glama
ParkBeomsoo

oss-analyzer

by ParkBeomsoo

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

C2.8/5.0

Scored across 31 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues