Skip to main content
Glama

Update project

save_content
DestructiveIdempotent

既存の 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。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes既存プロジェクトの id("d" で始まる内部ID。list_projects / create_content が返す id)
codesYes【必須形状】配列の中に必ず 1 件 id="adlRoot" isRoot=true lang="adl" のエントリを含める。adlRoot.data は ADL 構造を JSON.stringify した文字列。
notesNoAIが生成した変更サマリー。**配列**であること(文字列を渡すと引数エラーで拒否される)。例: [{ at: 1717200000, content: "S3バケット resource_storage を追加" }]。ここに入れた内容だけが構成図の「履歴」タブに変更サマリーとして残る(他に書き込む経路は無い)。
overviewYes更新後のメタ情報。titles/descriptions(複数形・locale-keyed map)、security(取扱情報種別: "publicHandling"|"confidentialHandling"|"privacyHandling")等を含む。type(公開設定)は private 固定。version は送っても無視される(サーバが採番する)。
allow_code_deletionNofull-replace で未指定の既存コードを削除することを明示的に許可する。通常は不要(既存プロビジョニングを保持するには全 codes を送る)。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint=true; the description explains the destruction concretely — unspecified existing files are deleted under full-replace, deletion requires allow_code_deletion, and unchanged files must be resent. It also discloses non-annotation behavior: server-side version increment, auto status logic, and secret masking returning a list of redacted locations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, auth, and sibling routing in the first sentence, then the destructive full-replace rule. Dense but every clause carries operational weight; a briefer invocation-side summary at top would help skimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, auth-gated mutation with no output schema, this covers auth, replacement semantics, required shape of codes/notes, server-controlled fields, masking behavior, and points to a guide for edge cases. Nothing material is omitted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline is 3, but the description adds cross-field meaning: codes shape matches create_content with one adlRoot entry, notes must be an array of {at,content}, and info.version/status in overview are server-controlled and ignored if sent. Slightly over-generous is avoided; these are genuine semantic additions beyond the schema strings.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (updates ADL and attachments of an existing IceShore project) and explicitly distinguishes itself from create_content for new creation and from commit_uploaded_codes for partial merges. An agent can route correctly without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when not to use it (create_content handles new), names the merge alternative (commit_uploaded_codes), and states the auth requirement plus required role (owner / admin / editor). Full-replace semantics vs partial merge is spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources