Context7
Up-to-date docs for AI agents
作者による説明(英語の原文)
Search IPCC AR6 WG1 and answer with page-level citations, or refuse when unsupported.
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
使っているAIアプリを選んで、設定をコピーしてください。
GEMINI_API_KEY, GOOGLE_GENAI_USE_VERTEXAI, GOOGLE_CLOUD_PROJECT「秘密」と表示された値は、あなたのアカウントの鍵です。絶対に人に教えたり、チャットに貼り付けたりしないでください。
必要なもの
どのアプリを使っていますか?
上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。
Claude Desktop → Settings → Developer → Edit Config を開き、claude_desktop_config.json にこれを貼り付けます
{
"mcpServers": {
"climate-ipcc-rag": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"GEMINI_API_KEY",
"-e",
"GOOGLE_GENAI_USE_VERTEXAI",
"-e",
"GOOGLE_CLOUD_PROJECT",
"ghcr.io/aswanisahoo/climate-ipcc-rag-mcp:0.1.0"
],
"env": {
"GEMINI_API_KEY": "your-value",
"GOOGLE_GENAI_USE_VERTEXAI": "your-value",
"GOOGLE_CLOUD_PROJECT": "your-value"
}
}
}
}ターミナルでこれを実行します
claude mcp add climate-ipcc-rag --env GEMINI_API_KEY=your-value --env GOOGLE_GENAI_USE_VERTEXAI=your-value --env GOOGLE_CLOUD_PROJECT=your-value -- docker run -i --rm -e GEMINI_API_KEY -e GOOGLE_GENAI_USE_VERTEXAI -e GOOGLE_CLOUD_PROJECT ghcr.io/aswanisahoo/climate-ipcc-rag-mcp:0.1.0動かす前に、空欄の値を入力してください。
プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます
{
"mcpServers": {
"climate-ipcc-rag": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"GEMINI_API_KEY",
"-e",
"GOOGLE_GENAI_USE_VERTEXAI",
"-e",
"GOOGLE_CLOUD_PROJECT",
"ghcr.io/aswanisahoo/climate-ipcc-rag-mcp:0.1.0"
],
"env": {
"GEMINI_API_KEY": "your-value",
"GOOGLE_GENAI_USE_VERTEXAI": "your-value",
"GOOGLE_CLOUD_PROJECT": "your-value"
}
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
プロジェクトの .vscode/mcp.json に貼り付けます
{
"servers": {
"climate-ipcc-rag": {
"type": "stdio",
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"GEMINI_API_KEY",
"-e",
"GOOGLE_GENAI_USE_VERTEXAI",
"-e",
"GOOGLE_CLOUD_PROJECT",
"ghcr.io/aswanisahoo/climate-ipcc-rag-mcp:0.1.0"
],
"env": {
"GEMINI_API_KEY": "your-value",
"GOOGLE_GENAI_USE_VERTEXAI": "your-value",
"GOOGLE_CLOUD_PROJECT": "your-value"
}
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
これはパソコンで動くサーバーですが、ChatGPTがつなげるのはインターネット上のサーバーだけです。ほかのアプリを選んでください。
選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。
GOOGLE_GENAI_USE_VERTEXAI envGOOGLE_CLOUD_PROJECT envこの設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。
パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月7日にチェック
レジストリ名は、リポジトリを所有するGitHubアカウント AswaniSahoo で確認済みです
このリポジトリはまだGitHubから読み取っていません
このリポジトリはまだGitHubから読み取っていません
これはパソコンで動くため、インターネット上のエンドポイントはありません
パソコンで動き、代わりにローカルの設定を使います
パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
入力が必要なもの:GEMINI_API_KEY
あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません(サーバー自体がオンラインサービスを呼び出す場合を除きます)。
GitHubリポジトリの最終更新は–、最新バージョン(0.1.0)がレジストリに届いたのは3 か月前です。
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにDockerも必要です。
同じカテゴリには:Context7, Codebase Memory, Exa
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i
Up-to-date docs for AI agents
Codebase knowledge graph for AI agents — 162 languages, sub-ms queries, 99% fewer tokens.
Connect AI agents to Exa for web search, content fetching, and multi-step research.
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
Ask a plain-language question about heat, extreme rain or wind anywhere on Earth, and get back a typed, cited risk report built from live forecast data, 60+ years of ERA5 extremes and IPCC AR6. When a question falls outside what it can check, it refuses instead of guessing.
Live demo: https://climate-risk-agent-714882950125.us-central1.run.app/ (a public Google Cloud Run deployment).
evals/results/warming-trend-2026-10-21.json, written by scripts/measure_warming_trend.py from a fresh ERA5 1960 to 2022 fit.The same report, scrolled down: the ERA5 return-level table with bootstrap confidence intervals, the warming-trend banner, and the measured cost and latency for that run.
A free-text question moves through parsing, geocoding and AR6 region mapping before it reaches the agent. From there a five-node LangGraph agent (plan, call, research, project, synthesize) either produces a typed RiskReport or refuses.
flowchart LR
Q[free-text question] --> PARSE[parse location · hazard · horizon] PARSE --> GEO[geocode Open-Meteo] GEO --> REGION[map to IPCC AR6 region reference regions v4] REGION --> PLAN[agent: plan scope check] PLAN -->|unsupported hazard| REFUSE[refusal valid typed output] PLAN --> CALL[agent: call forecast] CALL --> RESEARCH[agent: research] RESEARCH --> PROJECT[agent: project AR6 Ch.12 CID projection] PROJECT --> SYNTH[agent: synthesize] SYNTH --> REPORT[RiskReport typed · cited · grounded]
subgraph HAZARD [ERA5 to GEV hazard statistics] ERA5[ERA5 60+ yr annual maxima] --> GEV[stationary + drifting-location GEV] GEV --> LRT[likelihood-ratio test is the trend real?] LRT --> LEVELS[return levels + 90% bootstrap CI effective at latest year if trend holds] end CALL -.-> HAZARD HAZARD -.-> SYNTH
subgraph RAG [IPCC AR6 RAG] HYBRID[BM25 + dense hybrid RRF fusion] --> VALID[citations validated against retrieved pages] end RESEARCH -.-> RAG RAG -.-> SYNTH
The UI shows the same run as seven named steps, in this order (agent/progress.py): resolving location, fitting 60 years of ERA5 extremes, checking the question is in scope, fetching the forecast, searching IPCC AR6, reading Chapter 12 projections for your region, writing the cited report.
cid-table questions arrived with the Chapter 12 projection layer, and the set was re-frozen under a new SHA-256.Dev-set retrieval, all 60 questions (49 answerable), measured 2026-09-02:
| retriever | R@3 | R@5 | R@10 | MRR |
|---|---|---|---|---|
| BM25 only | 76% | 82% | 88% | 0.68 |
| dense only | 61% | 69% | 86% | 0.59 |
| hybrid (shipped) | 82% | 90% | 94% | 0.70 |
Per slice, hybrid R@3: single-page 92% (n=12), regional table 90% (n=10), multi-page 80% (n=10), premise injection 75% (n=4), cid-table 67% (n=15). cid-table is the weakest slice and is why the headline is 82% across all 60 questions where it was 91% across the original 45.
Dev-set end-to-end, all 60 questions (gemini-2.5-flash, top_k 8, scope guard stage 2 off, measured 2026-09-02):
| cell | count |
|---|---|
| correct answer | 48 |
| correct refusal | 11 |
| false refusal | 1 |
| false answer | 0 |
Citation validity 41/48 (85%). Numeric provenance 42/48 (88%). Grounded refusals 3/4. Cost $0.20 for the run, about $0.0034 per question, p50 latency 5.5 s across 55 model calls with 6 retried rate limits and no failures.
Held-out results (second exposure, on the exact configuration deployed):
Reranking and query rewriting: measured, kept off. Both are wired as HybridRetriever keyword arguments and both default to off. Measured on the 45-question dev set (34 answerable), before the cid-table questions landed:
| arm | R@3 | R@5 | R@10 | MRR | p50 | cost per question |
|---|---|---|---|---|---|---|
| hybrid (shipped) | 88% | 94% | 94% | 0.76 | 40 to 48 ms | $0 |
| + MiniLM cross-encoder | 79% | 85% | 91% | 0.68 | 4.0 s | $0 |
| + Gemini reranker | 82% | 94% | 94% | 0.74 | 38 s | $0.0123 |
| + query rewrite | 79% | 79% | 88% | 0.74 | 6.1 s | $0.0013 |
| + Gemini reranker and rewrite | 74% | 79% | 85% | 0.65 | 39 s | $0.0127 |
No arm beat the baseline at any k, and the cheapest of them costs about 100 times the latency. The seams stay in the code because the measurement is what makes leaving them off defensible.
Semantic scope guard, stage 2: measured, kept off. Stage 1 is lexical and runs before any model call. Stage 2 (rag/scope_semantic.py, CRG_SCOPE_STAGE2=off|embed|llm) reads only the questions stage 1 leaves undecided. Measured on the 45-question dev set, as correct answer / correct refusal / false refusal / false answer:
| arm | matrix | added latency per question | added cost per question |
|---|---|---|---|
| off (shipped) | 34/11/0/0 | 0 | $0 |
| embed | 33/11/1/0 | 24 ms | $0 |
| llm | 34/11/0/0 | 2.8 s | $0.00025 |
Zero false answers in every arm, and no arm gained anything, so the default stays off. The embed arm's one false refusal carries lexical hazard vocabulary and never reached stage 2. embed is the arm to promote, once a held-out run confirms the matrix holds. The full reasoning is in LIMITATIONS.md.
Every eval artifact records the model that produced it, because a model swap is invisible to a test suite. When the answering model was changed without re-running these evals, the benchmark caught a usefulness regression that the unit tests did not: see adr/0001-answering-model-selection.md.
Refusals are scored on a 4-cell confusion matrix (correct answer, correct refusal, false refusal, false answer). One false answer on that matrix blocks release.
The gate: it is an exit code, not an eyeball. The build fails on any false answer, on headline R@3 falling more than 3 points below the last committed run, or on the hybrid retriever being missing from the artifact, which would mean the run silently measured BM25-only. See DEPLOY.md.
Every hazard number rests on a forecast, and a peak predicted six days out is not the same claim as one predicted tomorrow. That gap is measured rather than assumed. scripts/measure_forecast_skill.py reads Open-Meteo's Previous Model Runs API, which archives what the model had predicted for each hour 1 to 7 days before it happened, and scores every lead time against the model's own day-0 run over 2024-01-0
冒頭だけを表示しています。続きはリポジトリで読めます