TowerWatch — 네트워크 품질 모니터링 프로젝트 — 위에 구축된 에이전트 레이어로, 엔터프라이즈 에이전트 엔지니어링 루프에 필요한 세 가지 역량을 입증하기 위해 만들어졌습니다: 평가 스위트, 비용/지연 시간 인지 모델 선택, 도구 검색. 하나의 저장소, 하나의 일관된 스토리:
"저는 공개 모니터링 프로젝트를 가져와서 엔터프라이즈가 필요로 하는 에이전트 레이어를 그 위에 구축했습니다: 정의된 SLI를 갖춘 계측된 MCP 서버, 시드된 회귀를 잡아내는 CI의 평가 하네스, 비용 인지 모델 라우터, 그리고 측정된 선택 정밀도를 갖춘 의미론적 도구 검색."
한눈에 보기
도메인: TowerWatch의 네트워크 모니터링 데이터를 에이전트 도구로 노출.
전송: stdio 우선; 무상태 스트리밍 HTTP는 스트레치 목표.
관측 가능성: 첫 도구 호출부터 OpenTelemetry, Prometheus/Grafana 스택으로.
도구 표면: 7개 도구 —
query_metrics,analyze_window,compare,query_log_events,get_monitor_status,get_runbook,run_speedtest. 계약은docs/design/에.상태: 🟡 Phase 1 진행 중 — 서버가 실행되고 7개 도구 중 1개가 구축됨; 아직 Phase 1 승인 기준을 충족하지 못함. 상태 참조.
"에이전트 평가와 라우팅에 대해 읽었다"와 "직접 구축하고 측정했다" 사이의 간극을 메웁니다. 모든 산출물 — 평가 테이블, 벤치마크 수치, precision@k 차트 — 은 연구에서 가져온 주장이 아니라 직접 수집한 숫자입니다. 도메인은 작성자가 이미 소유한 프로젝트의 실제 데이터이므로, 스토리는 "제 프로덕션 스타일 시스템을 확장했다"이지, "튜토리얼을 따라 했다"가 아닙니다.
빌드는 작성자 자신의 Agent Collaboration Principles에 따라 실행됩니다: 각 단계의 완료 정의는 독립적으로 확인 가능한 산출물 집합 — 실행되는 명령, 존재하는 파일, 렌더링되는 대시보드 — 입니다. "믿어주세요, 작동합니다"는 없습니다.
Related MCP server: production-grade-mcp-agentic-system
이 프로젝트는 엄격하게 순차적으로 진행되는 세 단계로 구성된 하나의 빌드입니다. 전체 사양은 docs/specs/에 있으며, 빌드 계획이 인덱스입니다. 요구사항은 계획 프로세스에서 사전에 정의되었고 계약으로 구축되었습니다 — 사양이 먼저였고, 도구 계약이 사양에서 파생되었으며, ADR은 표면을 형성한 모든 결정을 기록합니다.
단계 | 제공물 | 사양 |
1 | TowerWatch 데이터 위의 계측된 MCP 서버 + 정의된 SLI + 교차 모델 비용/지연 시간 벤치 | |
2 | CI에서 시드된 회귀를 잡아내는 골든 세트 + 루브릭 평가 하네스 | |
3 | 비용 인지 모델 라우터 + 측정된 선택 정밀도를 갖춘 의미론적 도구 검색 | |
횡단 관심사 | 에이전트 대상 문서, 저장소 내 스킬, ADR, 측정된 온보딩 평가 — 단계와 함께 점진적으로 추가되며, 차단하지 않음 |
순서는 엄격합니다: Phase 2의 평가가 Phase 3의 라우터를 평가합니다. 순서를 바꾸지 마세요. 횡단 관심사 레이어는 예외입니다 — 점진적으로 추가되며 아무것도 게이트하지 않습니다.
towerwatch-ops-agent/
├── README.md # this file — human-facing
├── CLAUDE.md # agent-facing anchor (read first if you're an agent)
├── pyproject.toml # PEP 621 single source of truth — deps, tooling config
├── docs/
│ ├── architecture.md # intended shape (stub — not built yet)
│ ├── specs/ # the governing build plan + 4 requirement specs
│ ├── design/ # locked tool contracts (00–11) — authoritative
│ ├── adr/ # architecture decision records
│ └── production-path.md # personal-scale choices vs. enterprise needs
├── src/towerwatch_ops_agent/ # server, config, domain/, tools/, telemetry/
├── tests/ # pytest suite — 95 tests
├── fixtures/stub/ # hand-authored stub corpus (not the real one)
└── RATIONALE.md # deliberate choices that read as defects서버가 실행되고
query_metrics를 제공합니다. 나머지 6개 도구는 아직 구축되지 않았습니다.
# From repo root. uv manages the environment and lockfile.
uv sync # create .venv, install deps from pyproject.toml
uv run python -m towerwatch_ops_agent # (Phase 1) launch the MCP server over stdio서버를 대화형으로 테스트하려면(Phase 1) MCP Inspector를 사용합니다:
npx @modelcontextprotocol/inspector uv run python -m towerwatch_ops_agent🟡 Phase 1 진행 중. MCP 서버가 stdio에서 실행되고 픽스처에 대해 query_metrics를 엔드 투 엔드로 제공합니다. Phase 1의 5가지 승인 기준 중 어느 것도 아직 충족되지 않았습니다 — 게이트 목록은 spec-phase1-mcp-server.md를 참조하세요.
구축되어 실행 중:
디렉터리 스켈레톤, pyproject.toml, .gitignore, MIT 라이선스
README, CLAUDE.md(바인딩 불변식 포함), 아키텍처 스텁
docs/specs/의 빌드 계획 및 4개 요구사항 사양 전체
잠긴 도구 계약 — docs/design/ 00–11: 규칙, 7개 도구 문서, 스킬 인터페이스, 스팬 스키마, 픽스처 매니페스트, 평가 설계
ADR — docs/adr/, 도구 표면 뒤의 결정들
MCP 서버 + 구성 루트 — server.py, config.py, stdio 전송
query_metrics — 7개 도구 중 1개, data_status 엔벨로프 적용
FixtureClient + 매니페스트 로더 — ADR-0002의 이중 모드 시임, 픽스처 측만
스팬 계측 — 도구 호출당 하나의 스팬, 비밀은 구조적으로 제외
CI 워크플로 — 모든 PR 브랜치 헤드에서 ruff, format, pyright, pytest
RATIONALE.md — 리뷰어가 결함으로 보고할 의도적 선택들
지연됨(아직 구축되지 않음 — 단계 게이트는 CLAUDE.md 참조):
나머지 6개 도구 — analyze_window, compare, query_log_events, get_monitor_status, get_runbook, run_speedtest
GrafanaCloudClient — DataClient 프로토콜의 라이브 절반
큐레이션된 픽스처 코퍼스 — fixtures/stub/은 형식만 증명하는 수작업 2-윈도우 스텁이며, 실제 결정적 코퍼스가 아님
OTel 익스포터 + SLI 대시보드 — 스팬이 생성되지만 아무데도 전송되지 않음; MeterProvider가 없어 지속 시간 히스토그램 없음
def_tokens.md — 도구 정의 토큰 예산 측정(스크립트는 존재하지만 실행된 적 없음)
bench.md — 교차 모델 비용/지연 시간 벤치
Phase 2 — 평가 하네스 + CI + 시드된 회귀 쇼케이스
Phase 3 — 모델 라우터 + 의미론적 도구 검색
.claude/skills/ 아래 저장소 내 스킬 — diagnose-rca, evidence-pack, 그리고 수동으로 처음 실행할 때 생성되는 골든 패스 스킬(add-tool, run-evals)
측정된 온보딩 평가(docs/onboarding-eval.md) — Phase 1 이후 첫 실행
이 저장소에서 작업하는 에이전트라면 먼저 **CLAUDE.md**를 읽으세요. 여기에는 단계 순서, 무상태 게이트 작업 표준, 그리고 존재하는 것과 여전히 스텁인 것의 명시적 지도가 있어 아직 없는 코드에 대해 추론하지 않도록 합니다. RATIONALE.md는 보자마자 결함으로 읽히는 의도적 선택들을 기록합니다 — 보고하기 전에 읽으세요.
Raw time-series data points from TowerWatch network monitoring.
Pick this when you need the actual numbers — specific values, series, timestamps — and you will do your own reasoning over them. If you want a judgment about a window (is it degraded, and against what reference), use analyze_window instead.
Returns downsampled [timestamp, value] pairs per metric, plus data_status. Read data_status before the numbers: 'empty_window' means collected here with nothing in range (a true negative), while 'not_collected' means this site never collects it — no evidence, so do not infer that anything is healthy.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| Name | Required | Description |
|---|---|---|
| error | No | Present only when data_status is 'error'. |
| series | No | Metric name to its downsampled points. Empty unless data_status is ok. |
| truncated | No | True when more points exist beyond this page. |
| data_status | Yes | ok=data present; empty_window=collected here, none in range (true negative); not_collected=site never collects this (NO evidence — do not infer health); partial=some groups missing; error=see message. |
| coverage_notes | No | Why data is missing or partial, in plain language. |
| next_page_token | No | Pass back as page_token to continue. Null when complete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and destructiveHint. The description adds meaningful behavioral context by explaining data_status semantics: 'empty_window' as a true negative versus 'not_collected' as no evidence, which is critical for interpreting results. It also discloses downsampling behavior and per-series output.
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?
Every sentence earns its place: purpose, usage selection, return format, and an important caveat about data_status. The structure is front-loaded and the caveat is placed where it will be read before acting on numbers.
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?
For a read-only query tool, the description covers when to use it, what it returns, and the crucial data_status interpretation. Pagination and request shape are documented in the schema, and there is an output schema, so the description is complete enough for an agent to call it correctly.
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%, and the description does not explain the primary request parameters such as site, start, end, metric_group, or pagination. It only implies per-metric and downsampled behavior. The nested schema helps, but the description itself does not compensate for the coverage gap.
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 states it returns raw time-series data points as downsampled [timestamp, value] pairs per metric, and explicitly distinguishes itself from analyze_window by saying this tool is for actual numbers while the sibling is for judgments. This gives an agent a clear, specific understanding of the tool's function.
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?
It explicitly says to pick this tool when actual numbers are needed and the agent will do its own reasoning, and directs users to analyze_window when they want a judgment about a window. This is clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.0.0towerwatch_query_metricsWith only one tool defined, there is no possibility of confusion between overlapping tools. The tool's purpose is clearly described, though it references a missing 'analyze_window' tool that does not exist in the server.
A single tool name following a clear prefix+verb_noun pattern (towerwatch_query_metrics) provides no inconsistency issues. There is no mix of conventions to evaluate.
A server with only one tool is very thin for a monitoring domain, especially since the description explicitly references a second tool ('analyze_window') that is absent. The scope is too narrow for an agent to perform useful monitoring workflows.
The tool only returns raw time series data and explicitly defers judgment to 'analyze_window', which is not implemented. This is a significant gap: agents cannot obtain window-level health assessments, and the missing referenced tool creates a dead end.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Monitoring for the agent economy — liveness, latency, trust scoring for MCP endpoints
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kemosabe102/towerwatch-ops-agent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server