TowerWatch — ネットワーク品質監視プロジェクト — の上に構築されたエージェント層で、エンタープライズのエージェントエンジニアリングループに必要な3つの能力、評価スイート、コスト/レイテンシを考慮したモデル選択、ツール検索を実証するためのものです。1つのリポジトリ、1つの一貫したストーリー:
「私は自分の公開監視プロジェクトを基に、その周りにエンタープライズが必要とするエージェント層を構築しました。定義された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/にあります。ステータス: 🟡 フェーズ1進行中 — サーバーは動作し、7つのツールのうち1つが構築済み。フェーズ1の受け入れ基準はまだ満たされていません。ステータスを参照。
「エージェントの評価とルーティングについて読んだ」と「実際に構築して測定した」の間のギャップを埋めるプロジェクトです。すべての成果物 — 評価テーブル、ベンチマーク数値、precision@kチャート — は、研究からの主張ではなく、作者自身が収集した数値です。ドメインは作者がすでに所有するプロジェクトの実データであるため、ストーリーは「チュートリアルをやった」ではなく「自分自身の本番スタイルのシステムを拡張した」というものです。
このビルドは作者自身のAgent Collaboration Principlesに基づいて実行されます。各フェーズの完了条件は、独立して検証可能な成果物のセットです — 実行されるコマンド、存在するファイル、レンダリングされるダッシュボード。「信じてください、動いています」という言葉はありません。
Related MCP server: production-grade-mcp-agentic-system
このプロジェクトは、厳密に順序付けられた3つのフェーズからなる1つのビルドです。完全な仕様はdocs/specs/にあり、ビルドプランが索引です。要件は計画プロセスで事前に定義され、契約として構築されました — 仕様が先にあり、ツール契約はそこから導出され、ADRはサーフェスを形作ったすべての決定を記録しています。
フェーズ | 提供物 | 仕様 |
1 | TowerWatchデータ上の計装化されたMCPサーバー + 定義されたSLI + クロスモデルのコスト/レイテンシベンチ | |
2 | シードされた回帰を検出するCI内のゴールデンセット + ルーブリック評価ハーネス | |
3 | コストを考慮したモデルルーター + 測定された選択精度を備えたセマンティックツール検索 | |
横断的 | エージェント向けドキュメント、リポジトリ内スキル、ADR、測定されたオンボーディング評価 — フェーズと並行して段階的に追加され、ブロックすることはありません |
順序は厳格です: フェーズ2の評価はフェーズ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サーバーを対話的にテストする(フェーズ1)には、MCP Inspectorを使用します:
npx @modelcontextprotocol/inspector uv run python -m towerwatch_ops_agent🟡 フェーズ1進行中。 MCPサーバーはstdio上で動作し、フィクスチャに対してquery_metricsをエンドツーエンドで提供します。フェーズ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のデュアルモードシーム、フィクスチャ側のみ
スパン計装 — ツールコールごとに1スパン、シークレットは構造的に除外
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 — クロスモデルのコスト/レイテンシベンチ
フェーズ2 — 評価ハーネス + CI + シードされた回帰のショーピース
フェーズ3 — モデルルーター + セマンティックツール検索
.claude/skills/配下のリポジトリ内スキル — diagnose-rca、evidence-pack、および手動で最初に辿ったときに作成されるゴールデンパススキル(add-tool、run-evals)
測定されたオンボーディング評価(docs/onboarding-eval.md) — フェーズ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