Skip to main content
Glama

会社情報を保存する

save_company_profile
Destructive

会社プロフィールを保存する(上書き)。以降のツールはこのプロフィールで判定する。

    必須の項目はない。わからない項目は省略する(判定では要確認として扱い、足りない情報として返す)。
    既存のプロフィールに足すときは get_company_profile の内容に足して保存する。
    search_keywords は事業内容から考えた2文字以上の短い語を5〜10個(例: ["設備投資", "IT導入", "DX", "販路開拓", "人材育成"])。
    purposes は利用者の「やりたいこと」(Webのフォームで選ぶもの)。get_company_profile にあれば引き継ぐ。
    company_name・representative・address(番地まで)・corporate_number は申請書類への記入に使う(Webでは入力しない)。
    様式に欄が出てきたとき(inspect_form の profile_candidates で value が null)に利用者に聞いて足す。
    plan の order_status・planned_start・planned_end・vendor は、利用者が言ったときだけ入れる。
    言っていない発注状況を「未着手」などと推測で入れない(空のままにすると、判定が発注状況を要確認として返し、利用者に聞ける)。
    planned_start・planned_end は事業の開始・完了予定日で、発注日ではない。利用者が言った日付をそのまま入れ、推奨日程に置き換えない。
    利用者の確認を得てから保存する。「サーバーに保存しない」設定の利用者では保存せず、設定の手順を返すので、それを伝える。
    

Input Schema

NameRequiredDescriptionDefault
planNo
companyYes
purposesNo
search_keywordsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / $defs / InvestmentPlan / properties / planned_end / description
      Added value: +"事業の完了予定日。利用者が言った日付をそのまま入れ、推奨日程に置き換えない"
    • addedInput schema / $defs / InvestmentPlan / properties / planned_start / description
      Added value: +"事業の開始予定日(発注日ではない)。利用者が言った日付をそのまま入れる"
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false and destructiveHint=true, and the description is consistent with them by stating 上書き (overwrite). Beyond annotations, it discloses important behavior: confirmation is required before saving, missing fields are treated as 要確認 and returned as missing information, order_status must not be guessed, planned dates are business dates rather than order dates, and the tool must not save when the user has disabled server-side saving.

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?

The purpose is front-loaded in the first sentence, followed by practical field-level guidance. The description is long, but the length is largely justified by the complexity of the profile, form-filling, privacy-setting, and no-guessing rules; only minor redundancy appears where it restates schema-level warnings such as not guessing order_status.

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 overwrite operation with four top-level parameters and a rich nested schema, the description covers the essential operator behavior: confirmation before saving, merging with get_company_profile, omitting unknown fields, form-driven elicitation, not inferring order status, honoring the user's server-saving preference, and using user-stated dates as-is. Because an output schema exists, it does not need to explain return values.

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

Parameters5/5

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

Top-level schema description coverage is reported as 0%, so the description must compensate, and it does: it defines search_keywords as 5–10 short terms of at least two characters derived from the business description, defines purposes as the user's selected goals and says to inherit them from get_company_profile when present, and explains the intended use of company_name, representative, address, and corporate_number in application forms. It also clarifies the plan fields: order_status, planned_start, planned_end, and vendor should only be entered when the user has stated them, and planned dates must not be replaced with recommended dates.

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?

The first sentence states a specific verb and resource: 会社プロフィールを保存する(上書き), and adds that later tools will use this profile. It also distinguishes the tool from get_company_profile by explaining that when adding to an existing profile, you should merge in the result of get_company_profile before saving.

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?

The description gives explicit when/when-not guidance: 必須の項目はない, omit unknown fields, ask the user when a form field appears with null profile_candidates, fill plan fields only when the user stated them, confirm before saving, and do not save for users configured not to save to the server. It also names the alternative workflow, using get_company_profile as the base when augmenting an existing profile.

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