Skip to main content
Glama

Create project

create_content

新しい 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 / localPath / 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。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codesYes【必須形状】配列の中に必ず 1 件 id="adlRoot" isRoot=true lang="adl" fmt="json" のエントリを含めること。adlRoot.data は ADL 構造(reindeer/self/info/actors/resources/useCases/components)を JSON.stringify した文字列。その他のエントリはプロビジョニングファイルを 1 件 1 エントリで isRoot=false として続ける。
overviewYesプロジェクト概要メタ。titles/descriptions(複数形・locale-keyed map)、version、type(visibility: "private"|"public")、security(取扱情報種別: "publicHandling"|"confidentialHandling"|"privacyHandling")等を含む。type と security は別概念。例: { titles: { en: "...", ja: "..." }, descriptions: { en: "...", ja: "..." }, version: "1.0.0", type: "private", security: "publicHandling" }
workspace_idNo登録先ワークスペース。"personal"(個人)または組織UUID(auth_check の organizations[].workspace_id)。【必須運用】依頼文(プロンプト)に登録先ワークスペースの指定があればその値を使う。指定が無い場合は auth_check で組織一覧を取得し、**必ずユーザーに登録先(個人 or 組織名)を確認してから**呼ぶこと。無断で個人に作成しない。組織を指定するには、その組織の編集権限(admin または editor。auth_check の organizations[].role で確認可能)が必要。省略時は個人ワークスペースに登録される(後方互換)。ワークスペースを指定できるのは新規作成時のみ。登録済み構成図のワークスペース変更は MCP からは不可(IceShore の Web 画面から行う)。

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 only declare the mutation/safety profile; the description adds auth requirements (login; org admin/editor or 403), irreversibility (workspace fixed at creation, cannot change via MCP), size limits (~5MB per call, 6MB sync ceiling), and a pre-save secret-masking behavior (***MASKED***). These are meaningful behavioral traits not derivable from annotations.

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-loaded with purpose, alternative routing, then format details; every section earns its place for a complex multi-part payload. However it is long and the codes example partly duplicates the schema, so it is not maximally tight.

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?

With no output schema, the description still documents the return (new id prefixed 'd' and diagram URL; ok:false + error on failure), the required overview contents, the document guides for ADL/IaC import/changelog, and the fallback path for oversized uploads. An agent has everything needed to call it correctly.

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 the baseline is 3, but the description adds real meaning beyond the schema: the consequence of missing adlRoot (screen renders empty), the distinction between lang (category) and fmt (file format), and the workspace_id default/confirmation rule. It stops short of only restating schema text.

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+resource (新しい IceShore プロジェクトを作る) with scope (ADL と添付ファイルを登録する), and explicitly distinguishes itself from the sibling save_content for updates. An agent can tell this apart from save_content without opening either schema.

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?

Explicit when-to-use and when-not: new creation vs save_content for updates, plus routing guidance for large uploads (batch_request_upload_url + commit_uploaded_codes over ~5MB) and a mandatory workspace-confirmation workflow before calling. Login and 403-on-missing-org-role conditions are stated.

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