IceShore
REMOTE · MCP.ICESHORE.AI
Make your AI better at system maintenance. Prompts your AI to organize use cases behind each system.
Available components
Last scanned (1 hour ago)
Scores higher than 96% of remote servers
Reachable. Last reached 6 Nov 2026.
Category Developer Tools
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security89
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability76
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 12289 tokens (~341/item across 36 items; 16 tools + 20 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 18 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities40
- Spec-recency check failed: implements MCP spec 2025-03-26; the latest is 2026-07-28. See how to fix → Fail
Checks we ran (13)
- TLS certificate
- Authorization
- HTTPS
- HSTS header
- DNSSEC
- Transport
- Schema quality
- Stability
- Tool coverage
- Injection markers
- Destructive annotations
- Judged manipulation
- MCP protocol
Does not apply to this hosted endpoint (2)
- Supply Chain SecurityScored on package channels only. This is a hosted endpoint, so there is nothing to install or inspect.
- Provenance & TransparencyScored on package channels only. This is a hosted endpoint, so there is nothing to install or inspect.
The score does not measure everything. What the score does not measure →
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 6 Nov 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 5 Nov 26 0
- Tool “commit_uploaded_codes” rewrote its description, which is the text the model reads security
- Tool “create_content” rewrote its description, which is the text the model reads security
- “commit_uploaded_codes” added an optional parameter “notes” cosmetic
- 4 Nov 26 +1
- Stability: 0.97 → pass security
- 2 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.
- 30 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 28 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 73 to 77. That category is still filling its 30-day observation window: 22 days of observed history at the previous scan, 23 at this one. The score rises as the window fills, whether or not the server changes.
- 26 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 67 to 70. That category is still filling its 30-day observation window: 20 days of observed history at the previous scan, 21 at this one. The score rises as the window fills, whether or not the server changes.
- 24 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 6 Nov 2026 · Probed https://mcp.iceshore.ai/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=iceshore.ai | CN=Amazon RSA 2048 M01,O=Amazon,C=US | 25 Jun 2026 | 8 Jan 2027 | RSA 2048 | SHA256-RSA | c604f82bab7bdf3073462b11a5ca19b |
| SANs: iceshore.ai, *.iceshore.ai | ||||||
| CN=Amazon RSA 2048 M01,O=Amazon,C=US (CA) | CN=Amazon Root CA 1,O=Amazon,C=US | 23 Aug 2022 | 23 Aug 2030 | RSA 2048 | SHA256-RSA | 77312380b9d6688a33b1ed9bf9ccda68e0e0f |
| CN=Amazon Root CA 1,O=Amazon,C=US (CA) | CN=Starfield Services Root Certificate Authority - G2,O=Starfield Technologies\, Inc.,L=Scottsdale,ST=Arizona,C=US | 25 May 2015 | 31 Dec 2037 | RSA 2048 | SHA256-RSA | 67f944a2a27cdf3fac2ae2b01f908eeb9c4c6 |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mcp.iceshore.ai. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | Trust anchor | 20326, 38696 | 8, 8 | Verified |
| ai. | DS published | 1814, 3799 | 8, 8 | Verified |
| iceshore.ai. | No DS | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer resource_metadata="https://mcp.iceshore.ai/.well-known/oauth-protected-resource"
Bearer resource_metadata="https://mcp.iceshore.ai/.well-known/oauth-protected-resource" Protected resource metadata
| Document | https://mcp.iceshore.ai/.well-known/oauth-protected-resource |
|---|---|
| Retrieved | Yes |
| Resource | https://mcp.iceshore.ai/mcp |
| Authorisation server | https://api.iceshore.ai |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.iceshore.ai/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.iceshore.ai/mcp | HTTPS enforced | 301 | https://mcp.iceshore.ai/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
add_note Add or update note ~508
ADL のノードに、規範的な注意点(humanNote)を保存する(ログインが必要・editor または admin 権限)。同じ ref_path への保存は上書き(UPSERT)で、1 ノードに有効なノートは最大 1 件。 text: 200 字以内。「〜のため〜にする」「〜なので〜禁止」の規範の形。固有名詞は書ける。1 ノードの複数の観点は 1 文にまとめて書く。 ref_path はサーバが ADL と照合する: 見つからないときは reason="ref_path_not_found" と、当たった最長の前置(matched_prefix)、そこにあるキー(candidates)を返す。ADL が読めないときは reason="adl_unavailable"。"$ref" の先はたどらない。ADL に "contexts" という欄は無い(実体は "useCases")。 ノートの下書きをローカルにためてから保存する進め方は iceshore://guide/common に書いてある。 入力: content_id, ref_path, text, lang(すべて必須)。 出力: { ok, mode: "inserted"|"updated", defined_at, updated_at }。
| Name | Type | Req | Description |
|---|---|---|---|
| content_id | string | yes | IceShore プロジェクト ID("d" で始まる内部ID。list_projects が返す id。"I…" 形式は使用不可) |
| lang | string | yes | ISO 639-1 言語コード(例: "en", "ja") |
| ref_path | string | yes | 対象ノードの ref_path(例: "#/actors/customer", "#/useCases/uc1/traffics/t1")。ADL 内に実在するノードを指すこと(サーバが照合し、外れると reason="ref_path_not_found" と candidates を返す)。`contexts` という欄は無い=`useCases` |
| text | string | yes | 規範形の注意点(200 文字以内)。"〜のため〜にする" / "〜なので〜禁止" の形式。事後報告や抽象表現は禁止 |
No output schema declared.
No examples provided.
auth_check Check connection ~131
IceShore への接続と認証の状態を返す。 入力: なし。 出力: 認証成功なら userId と所属組織一覧(organizations: workspace_id / name / role)、失敗(トークンの無効・失効など)なら error を含む文字列。 organizations[].workspace_id は、create_content / commit_uploaded_codes の登録先(workspace_id)や list_projects の絞り込みに使える値。 組織への登録ができるのは、role が admin または editor の組織。
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
batch_request_upload_url Request upload URLs ~359
複数のプロビジョニングファイルの presigned PUT URL を、1 回の呼び出しで N 件(最大 100)発行する(ログインが必要)。 各 upload_url は HTTP PUT でファイル本体を受け付ける(有効期限 10 分・並列可)。シェルを実行できるクライアントでの例: curl --silent --show-error --fail -X PUT --upload-file <ローカルパス> '<upload_url>'。 アップロードしたファイルは commit_uploaded_codes で構成図に取り込まれる。ADL 本体(adr)も 1 ファイル分足して送れ、commit_uploaded_codes の code_entries で is_root:true を付けると inline の adl_root が要らない。 urls[] の順序は入力 files[] と同じ。同じバッチに同じ code_id が 2 件あるとエラー。staging はユーザ × project_id ごとに分かれる。 入力: files(1〜100 件・必須)、project_id(追記時)。 出力: project_id, urls: [{code_id, upload_url, content_key}, ...], expires_in(=600)。
| Name | Type | Req | Description |
|---|---|---|---|
| files | array | yes | アップロード対象のファイルメタ情報。同じ project_id に紐付く N 件をまとめて発行する。 |
| project_id | string | – | 既存プロジェクトに追記する場合のみ指定。新規作成では未指定で呼び出すと、サーバが project_id を採番して返す。 |
No output schema declared.
No examples provided.
commit_uploaded_codes Add uploaded files to project ~1,212
request_upload_url / batch_request_upload_url の URL へ PUT したファイルを、IceShore プロジェクトの codes に取り込む(ログインが必要)。新規プロジェクトはこの呼び出しで作られ、既存プロジェクトにはマージ(MERGE)で追記・更新し、指定しなかった既存ファイルは温存する。 マージのルール: code_id が一致すれば上書き、新しい code_id は末尾に追加、code_entries に無い既存ファイルはそのまま残る(save_content の全置換とは違う)。adl_root(または is_root:true のエントリ)を渡すと ADL 本体を置き換え、省くと既存のまま。 ADL 本体の渡し方は 2 通り: code_entries の 1 件に is_root:true(staged 経由・大きな ADL 向け)、または引数 adl_root に JSON 文字列(inline・小さな ADL 向け)。両方あれば inline を使う。旧称 cloud_design_root も受け付ける。 品質評価(KGI)と構成図は保存時にサーバ側で作られるので、画面で保存し直す必要はない。info.version と info.status もサーバが決める(version は保存のたびに +1 される整数、status は品質評価から designed / prepared / draft を自動で決める)。応答には構成図の URL が含まれる。 code_entries の各 code_id は、PUT 済みでなければ 400。is_root:true は 1 件まで。ファイルの削除は扱わない(delete_code または save_content)。 notes(任意・配列): 変更の 1 行要約。save_content と同じ形で、構成図の「履歴」タブに残る。応答の「記録した変更サマリー: N 件」が記録された件数。 入力: project_id(必須)、code_entries(必須・空配列可)、adl_root(新規時に必要・staged の is_root があれば不要)、overview(新規時に必要)、workspace_id(新規時の登録先)、notes。 出力: id と構成図の URL。
| Name | Type | Req | Description |
|---|---|---|---|
| adl_root | string | – | ADL 構造を JSON.stringify した文字列。新規登録 (= request_upload_url で project_id を新規採番した最初の commit) では **必須**。既存プロジェクトの更新で構造を変えないなら省略可(既存値が保持される)。(旧称 cloud_design_root は後方互換のため引き続き受け付ける) |
| cloud_design_root | string | – | 非推奨。adl_root の旧称。後方互換のため受け付ける。新規コードでは adl_root を使うこと。 |
| code_entries | array | yes | curl PUT で staging に置いた各ファイルのメタデータ。**ファイル中身 (data) は含めない**(サーバが S3 staging から読む)。差分アップロードでは「変更したファイルだけ」を列挙する。空配列は cloud_design_root / overview 単体の更新時に許容。 |
| notes | array | – | AIが生成した変更サマリー。**配列**であること(文字列を渡すと引数エラーで拒否される)。例: [{ at: 1717200000, content: "S3バケット resource_storage を追加" }]。ここに入れた内容だけが構成図の「履歴」タブに変更サマリーとして残る(他に書き込む経路は無い)。 |
| overview | string | – | プロジェクト概要メタ (titles / descriptions / version / security 等。titles/descriptions は複数形・locale-keyed map。security は取扱情報種別 "publicHandling"|"confidentialHandling"|"privacyHandling"。type(公開設定)は MCP 経由では常に pr… |
| project_id | string | yes | request_upload_url で得た project_id を必ず渡す |
| workspace_id | string | – | 登録先ワークスペース(新規登録時のみ有効)。"personal"(個人)または組織UUID(auth_check の organizations[].workspace_id)。【必須運用】依頼文(プロンプト)に登録先ワークスペースの指定があればその値を使う。指定が無い場合は auth_check で組織一覧を取得し、**必ずユーザーに登録先(個人 or 組織名)を確認してから**呼ぶこと。無断… |
No output schema declared.
No examples provided.
create_content Create project ~1,075
新しい IceShore プロジェクトを作る(ADL と添付ファイルを登録する。ログインが必要)。既存プロジェクトの更新は save_content が扱う。 codes の形: 配列のうち 1 件が ADL 本体(id="adlRoot", isRoot=true, lang="adl", fmt="json", data=ADL を JSON.stringify した文字列)。残りはプロビジョニングファイルを 1 件 1 エントリ(isRoot=false)。ADL 本体が無いと画面では空になる。ADL の構造は iceshore://guide/adl に書いてある。 例: { "codes": [ { "id": "adlRoot", "isRoot": true, "lang": "adl", "fmt": "json", "data": "{"reindeer":"2.0.0","self":"adl.json",...}" }, { "id": "main.tf", "isRoot": false, "lang": "tfm", "fmt": "hcl", "data": "resource "aws_lambda_function" ..." } ], "overview": { "titles": {"en": "...", "ja": "..."}, "descriptions": {"en": "...", "ja": "..."}, "version": "1.0.0", "type": "private", "security": "publicHandling" } } overview は必須。IaC リポジトリからの新規インポートでは importSource(originUrl / lastImportedCommit / lastImportedAt / importMethod。手元のフォルダのパスは送らない)を、変更履歴として changeLog(at / by / source / summary / delta / securityNotices)を持てる(iceshore://guide/iac-import・iceshore://guide/changelog)。 workspace_id: "personal"(個人)または組織の ID(auth_check の organizations[].workspace_id)。省くと個人。組織への登録にはその組織の admin / editor 権限が要り、無ければ 403。登録先は作成時だけ指定でき、後から MCP では変えられない(画面から変える)。 大きさ: 1 回あたり約 5 MB まで(同期リクエストの上限 6 MB)。合計が大きいとき・ファイルが多いときは batch_request_upload_url + commit_uploaded_codes の経路がある。 保存前に、アクセスキー・パスワード・トークンなどに見える値は ***MASKED*** に置き換えて保存する。 出力: 新しい id("d" で始まる内部 ID)と構成図の URL。失敗時は ok:false と error。
| Name | Type | Req | Description |
|---|---|---|---|
| codes | array | yes | 【必須形状】配列の中に必ず 1 件 id="adlRoot" isRoot=true lang="adl" fmt="json" のエントリを含めること。adlRoot.data は ADL 構造(reindeer/self/info/actors/resources/useCases/components)を JSON.stringify した文字列。その他のエントリはプロビジョニングファイル… |
| overview | string | yes | プロジェクト概要メタ。titles/descriptions(複数形・locale-keyed map)、version、type(visibility: "private"|"public")、security(取扱情報種別: "publicHandling"|"confidentialHandling"|"privacyHandling")等を含む。type と security は別概念。… |
| workspace_id | string | – | 登録先ワークスペース。"personal"(個人)または組織UUID(auth_check の organizations[].workspace_id)。【必須運用】依頼文(プロンプト)に登録先ワークスペースの指定があればその値を使う。指定が無い場合は auth_check で組織一覧を取得し、**必ずユーザーに登録先(個人 or 組織名)を確認してから**呼ぶこと。無断で個人に作成しない。組… |
No output schema declared.
No examples provided.
delete_code Delete project file ~188
プロジェクトの codes から 1 件のファイルを削除する(ログインが必要)。ADL 本体(adlRoot)は削除できない(必要なら save_content の全置換)。 1 ファイル分の読み書きだけで済み、全 codes を送り直す save_content より速い。構成図は保存時にサーバ側で作り直される。 入力: project_id, code_id(どちらも必須)。 出力: { ok: true, id, removed: true|false }。removed:false は、その code_id が元から無かったことを示す。
| Name | Type | Req | Description |
|---|---|---|---|
| code_id | string | yes | 削除するファイルの code_id (例 "old.tf")。adlRoot は不可。 |
| project_id | string | yes | IceShore プロジェクト ID |
No output schema declared.
No examples provided.
delete_note Delete note ~149
ADL ノードの humanNote を論理削除する(is_deleted=1・ログインが必要・editor または admin 権限)。行は消さないので、同じ ref_path に add_note すると復活する。 入力: content_id, ref_path(どちらも必須)。 出力: { ok, mode: "deleted"|"not_found" }。
| Name | Type | Req | Description |
|---|---|---|---|
| content_id | string | yes | IceShore プロジェクト ID("d" で始まる内部ID。list_projects が返す id。"I…" 形式は使用不可) |
| ref_path | string | yes | 対象ノードの ref_path |
No output schema declared.
No examples provided.
find_content_by_source Find project by source ~205
git の origin URL(またはローカルの絶対パス)から、IceShore のプロジェクト(ADL)を探す(ログインが必要)。 用途: IaC のインポート前に、同じリポジトリがインポート済みかを調べる(済みなら更新 = save_content、未なら新規 = create_content の対象になる)。手順は iceshore://guide/iac-import に書いてある。 入力: origin_url。 出力: 見つかれば found=true と id・title・updatedAt、無ければ found=false。
| Name | Type | Req | Description |
|---|---|---|---|
| origin_url | string | yes | リポジトリのgit remote origin URL。例: "git@github.com:org/repo.git" または "https://github.com/org/repo.git"。git remoteがない場合はリポジトリの絶対パスを使用。 |
No output schema declared.
No examples provided.
get_content Get project ~436
【認証不要(公式サンプルの公開コンテンツのみ)】匿名では公式サンプルだけを返し、それ以外はログインが必要(401)。IceShore プロジェクト 1 件の ADL と添付ファイルを返す。 用途: 既存プロジェクトの参照、保存・更新の結果の確認(get_content(mode='detail') の戻りが保存後の実際の状態の正典)。 id は list_projects または list_samples が返す、"d" で始まる内部 ID。 mode の違い: - "meta": メタ情報だけ。S3 を読まないので速い(10 秒以上短い) - "root": ADL 本体(adlRoot)だけ - "detail": 全ファイル。大きく、30 秒ほどかかる場合がある 出力: { code, id, mode, data, type, role, ownerID, ... }。
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | IceShore プロジェクト ID("d" で始まる内部ID。list_projects / create_content が返す id。例: d9289696c392a29e188.13397864。URL スラグの "I…" 形式は使用不可) |
| locale | string | – | 表示ロケール (en/ja 等)。省略時は en |
| mode | string | – | 取得モード。 - "meta" (速い・推奨デフォルト): 重い codes blob を S3 から読まない。overview/role 等のメタ情報のみ。10 秒以上短縮可。 - "root" (中): codes を adlRoot 1 件に絞る。ADL 構造だけ欲しい時。 - "detail" (既定値、重い): 全 codes を返す。プロビジョニングファイル全件を参照する… |
No output schema declared.
No examples provided.
get_guide Get guide ~267
【認証不要】匿名(未ログイン)でも使える。IceShore のガイド文書(ADL の書き方・登録手順・分析の進め方など)を名前で返す。 MCP リソースに対応していないクライアント向けの取得手段で、対応クライアントは resources/read でも同じ内容を読める。 主な名前: "analysis"(業務影響・依存・外部波及の分析)/ "registration"(システム登録)/ "fix"(ADL の修正)/ "adl"(ADL の作り方)/ "saving-publishing"(保存と公開)。 入力: name(短縮名または URI パス)。知らない name のときは、使える名前の一覧を返す。 出力: ガイド本文(markdown / JSON。本文は英語)。
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | ガイド名。短縮名(例 "analysis" / "registration" / "fix" / "adl" / "saving-publishing")または URI パス(例 "guide/analysis" / "skill/adl-validator")。 |
No output schema declared.
No examples provided.
get_notes Get notes ~325
プロジェクトの humanNote(人が ADL のノードに残した規範的な注意点)を返す(ログインが必要)。1 ノード(ref_path)につき有効なノートは最大 1 件。 用途: 既存プロジェクトを編集するときの確認、人が編集した形跡(_meta.d が "h:" で始まる)のあるノードの参照、特定ノードについての質問への回答。 refs(任意・配列): 取得するノードの ref_path。省くと全件(最大 500 件)。 ref_path が今の ADL に無いノートは、ノードの削除や改名で取り残されたもの。 出力: { code, id, data: { notes: [{ note_id, ref_path, text, lang, defined_by, defined_at, updated_at }] } }。
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | IceShore プロジェクト ID("d" で始まる内部ID。list_projects / create_content が返す id。例: d9289696c392a29e188.13397864。URL スラグの "I…" 形式は使用不可) |
| refs | array | – | 対象ノードの ref_path 配列(例: ["#/actors/customer", "#/useCases/uc1/traffics/t1"])。省略時は全件(500 件まで) |
No output schema declared.
No examples provided.
list_codes_meta List project files ~208
既存プロジェクトの codes 配列のメタデータ一覧を返す(ファイル中身 data は含まない)。差分アップロードの判定に使う。 各エントリの sha256 は、data フィールド(文字列)を SHA-256 にかけた値。テキストファイルなら、ローカルの shasum -a 256 <file> の結果と一致する。 sha256 が一致するファイルは変更なしで、不一致または一覧に無いファイルだけを request_upload_url / batch_request_upload_url → commit_uploaded_codes で送れば足りる。 入力: project_id。 出力: codes: [{code_id, isRoot, lang, fmt, size, sha256}]。
| Name | Type | Req | Description |
|---|---|---|---|
| project_id | string | yes | 対象プロジェクトの id("d" で始まる内部ID。list_projects が返す id) |
No output schema declared.
No examples provided.
list_projects List projects ~544
ユーザが閲覧権限を持つプロジェクト(ADL 構成図)の一覧を返す(ログインが必要)。 用途: 作業対象のプロジェクトの特定。業務影響・規模・依存関係を分析するときに、get_content で ADL を取る前の起点になる。 ページング: 既定は page=0 / itemperpage=24。続きは page=1, 2, …。itemperpage の最大は 100。 サンプルとの関係: range を省くと range="related" と同じで、公式サンプルは含まない(サンプルは list_samples が返す)。 workspace_id を渡すと、その 1 組織が所有する案件だけに絞り込む(値は auth_check の organizations[].workspace_id)。 入力: range, page, itemperpage, workspace_id(すべて省略可)。 出力: プロジェクトの id とタイトルの一覧(プレーンテキスト)。末尾に total / totalPages。
| Name | Type | Req | Description |
|---|---|---|---|
| itemperpage | integer | – | 1 ページあたりの件数 (default 24、最大 100)。 |
| page | integer | – | 0 起点のページ番号 (default 0)。default の itemperpage=24 件単位でページング。 |
| range | string | – | 取得スコープのフィルタ。"related" (省略時の既定) = 自分が role を持つ構成図 + 自分の組織の構成図。誰でも見える公開構成図(公式サンプル)は足さない。"" = related に加えて公開構成図も含める(サンプルは list_samples を使うこと)。"bookmark" = bookmark 済のみ。"private" = type=private のみ。"priva… |
| workspace_id | string | – | 特定の組織(ワークスペース)に絞り込む。auth_check が返す organizations[].workspace_id をそのまま渡す。複数組織に所属するユーザでも、指定した 1 組織が所有する案件のみが返るため、組織を跨いだ取りこぼし・混入を防げる。省略時は全所属組織の構成図が混在する。 |
No output schema declared.
No examples provided.
list_samples List sample projects ~236
【認証不要】匿名(未ログイン)でも使える。公式サンプルワークスペースの公開構成図の一覧を返す(ログイン時も公式サンプルワークスペースに固定)。 用途: 新しい設計の参考事例、サンプルを土台にした作成。 list_projects との違い: list_projects は自分が閲覧権限を持つプロジェクト(サンプルを含まない)、本ツールは公式サンプルだけ。 ページング: 既定は page=0 / itemperpage=24。 入力: page, itemperpage(すべて省略可)。 出力: 公開プロジェクトの id とタイトルの一覧。末尾に total / totalPages。
| Name | Type | Req | Description |
|---|---|---|---|
| itemperpage | integer | – | 1 ページあたりの件数 (default 24、最大 100)。 |
| page | integer | – | 0 起点のページ番号 (default 0)。default の itemperpage=24 件単位でページング。 |
No output schema declared.
No examples provided.
request_upload_url Request upload URL ~610
プロビジョニングファイル 1 件分の、S3 への presigned PUT URL を発行する(ログインが必要)。ファイルが複数なら batch_request_upload_url が 1 回で N 件を発行する。 返る upload_url は HTTP PUT でファイル本体を受け付ける(有効期限 10 分)。シェルを実行できるクライアントでの例: curl --silent --show-error --fail -X PUT --upload-file <ローカルパス> '<upload_url>'。ファイル中身はディスクから S3 へ直接送られ、会話の出力トークンにならない。シェルを使えないクライアントでは、create_content / save_content が中身を引数で受け取る。 アップロードしたファイルは commit_uploaded_codes で構成図に取り込まれる。ADL 本体(adr)も同じ経路で送れ、commit_uploaded_codes の code_entries で is_root:true を付けると inline の adl_root が要らない。 project_id を省くと新しい project_id を採番する。同じ project_id で同じ code_id を発行し直すと、commit 時に後のものが使われる。staging はユーザ × project_id ごとに分かれ、他ユーザの project_id には発行できない(403)。 入力: code_id, lang, fmt(必須)、project_id(追記・更新時)。 出力: upload_url, content_key, project_id, expires_in。
| Name | Type | Req | Description |
|---|---|---|---|
| code_id | string | yes | プロビジョニングファイルのファイル名 (例 "main.tf" / "serverless.yml" / "template.yaml")。S3 のキーに直接使うので [A-Za-z0-9._-] のみ・最大 200 文字。 |
| fmt | string | yes | ファイル形式 (json / yaml / hcl の 3 値のみ。.tf/.tfvars/.hcl→hcl、.yml→yaml)。 |
| lang | string | yes | カテゴリ。acf=CFn / tfm=Terraform / slf=Serverless / arm=ARM / gdm=GDM / cim=CIM / aro=ROS / oth=その他。【最頻出ミス】拡張子と取り違えるな。yaml/json は fmt フィールドに入れる |
| project_id | string | – | 既存プロジェクトに追記する場合のみ指定。新規作成では未指定で呼び出すと、サーバが project_id を採番して返す。同じセッションの 2 回目以降は返ってきた project_id を渡す。 |
No output schema declared.
No examples provided.
save_content Update project ~843
既存の IceShore プロジェクトの ADL と添付ファイルを更新する(ログインが必要・所有者または admin / editor 権限)。新規作成は create_content が扱う。 全置換(full-replace): codes に渡したものがすべてになり、未指定の既存ファイルは削除される(allow_code_deletion を付けたときだけ削除を受け付ける)。既存ファイルを残すには、変更しないものも含めて全 codes を送る。現在の codes は get_content(mode='detail') で取れる。一部のファイルだけ足す・直すなら、マージする commit_uploaded_codes がある。 codes の形は create_content と同じ(1 件が ADL 本体 adlRoot)。overview は必須。 notes(任意・配列): 変更の 1 行要約。[{ at: <UNIX 秒・整数>, content: "<100 字以内>" }] の形で、構成図の「履歴」タブに残る。応答の「記録した変更サマリー: N 件」が記録された件数。 info.version と info.status はサーバが決める: version はサーバが採番し、保存のたびに +1 される整数(送った値は使われない)、status は品質評価から designed / prepared / draft を自動で決める("reviewed" は自動では下げない)。応答の「改訂 N / status: X」が保存後の値。 品質評価(KGI)と構成図は保存時にサーバ側で作られる。 IaC から更新するときに人が足した内容(resources[*].lessons、useCases[*].notes、IaC に無い actors など)の扱いは iceshore://guide/iac-import に書いてある。 保存前に、アクセスキー・JWT・秘密鍵・接続文字列などに見える値は ***MASKED*** に置き換えて保存し、置き換えた箇所を応答に一覧で返す。 入力: id(必須)、codes(必須)、overview(必須)、notes、allow_code_deletion。
| Name | Type | Req | Description |
|---|---|---|---|
| allow_code_deletion | boolean | – | full-replace で未指定の既存コードを削除することを明示的に許可する。通常は不要(既存プロビジョニングを保持するには全 codes を送る)。 |
| codes | array | yes | 【必須形状】配列の中に必ず 1 件 id="adlRoot" isRoot=true lang="adl" のエントリを含める。adlRoot.data は ADL 構造を JSON.stringify した文字列。 |
| id | string | yes | 既存プロジェクトの id("d" で始まる内部ID。list_projects / create_content が返す id) |
| notes | array | – | AIが生成した変更サマリー。**配列**であること(文字列を渡すと引数エラーで拒否される)。例: [{ at: 1717200000, content: "S3バケット resource_storage を追加" }]。ここに入れた内容だけが構成図の「履歴」タブに変更サマリーとして残る(他に書き込む経路は無い)。 |
| overview | string | yes | 更新後のメタ情報。titles/descriptions(複数形・locale-keyed map)、security(取扱情報種別: "publicHandling"|"confidentialHandling"|"privacyHandling")等を含む。type(公開設定)は private 固定。version は送っても無視される(サーバが採番する)。 |
No output schema declared.
No examples provided.
How do I install the IceShore MCP server?
IceShore is a hosted endpoint at https://mcp.iceshore.ai/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · mcp.iceshore.ai
claude mcp add --transport http ai-iceshore-iceshore 'https://mcp.iceshore.ai/mcp'
What is the IceShore MCP server?
IceShore is an MCP server listed in the public MCP registry as ai.iceshore/iceshore. Make your AI better at system maintenance. Prompts your AI to organize use cases behind each system. This page covers its hosted endpoint (https://mcp.iceshore.ai/mcp).
Is the IceShore MCP server safe to use?
IceShore scores 89 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the IceShore MCP server expose?
IceShore exposes 16 tools: auth_check, list_projects, list_samples, get_guide, get_content, and 11 more. Their descriptions and schemas cost roughly 7,296 tokens of context every time the server is loaded.
Does the IceShore MCP server require authentication?
Yes. IceShore asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the IceShore MCP server still maintained?
IceShore is still listed as active in the MCP registry. We last reached this channel on 6 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What did VerifyMCP test on the IceShore MCP server?
VerifyMCP ran 13 checks on IceShore, covering TLS certificate, Authorization, HTTPS, HSTS header and 9 more. Supply Chain Security and Provenance & Transparency do not apply to a hosted endpoint, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.