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

Annotations already indicate this is a mutating operation (readOnlyHint false) and not idempotent. The description adds the tenant-scope and plan-requirement context, which is useful. However, it does not disclose potential side effects such as duplicate handling or immediate enforcement, but given annotation coverage, this is acceptable.

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

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

The description is a single concise sentence that front-loads the action and resource, then mentions required parameters. There is no filler or redundant content.

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

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

For a simple two-parameter create operation with an output schema, the description covers the needed context: what is added, at what scope, and which parameters are required. A small gap is the lack of any note about response or edge cases, but the output schema likely covers return value expectations.

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

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

Schema description coverage is 100%, with both parameters already described ('許可 CIDR', '対象プロジェクト UUID'). The description only restates that these are required, adding no new semantic information beyond the schema. Baseline 3 applies.

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

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

Description states a specific action ('追加' / add), a clear resource ('管理画面ログイン IP 許可ルール'), and the scope ('Business+・tenant スコープ'). It clearly distinguishes from sibling tools list_console_login_ip_allowlists and delete_console_login_ip_allowlist by indicating this one creates a new rule.

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

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

The description provides applicable context: it is restricted to Business+ plan and tenant scope, which helps an agent decide when this tool is appropriate. It does not explicitly name alternatives or exclusion conditions, but the add-vs-list/delete contrast with sibling tools is reasonably clear.

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

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

Annotations already indicate idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds useful behavioral context beyond that: create-only semantics, the returned id should be used as formSetId, dryRun previews without creating, and templateSlug/templateId XOR requirement. It does not contradict the annotations.

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

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

The description is dense but each clause contributes something: purpose, required fields, template selection rules, optional fields, exclusions, return-value usage, and a details reference. It could be more structured with line breaks, but it is appropriately sized and front-loaded with the core purpose.

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

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

Given the 7 parameters, output schema, and annotations, the description covers the essential constraints: required fields, template selection options, exclusions, and use of the returned id. The phrase 'schema/full' and the details reference are somewhat opaque, and the inquiry exclusion does not name an alternative, but these are minor gaps.

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

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

Schema description coverage is 100%, so the schema already documents individual parameters. The description adds real value by clarifying that slug is NOT the template slug, that templateSlug is recommended while templateId is legacy, that one of them is required, and which parameters are optional. This is meaningful guidance beyond the schema.

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

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

The description states a specific action and resource: create a new Form Set from a builtin form template. It explicitly distinguishes itself from apply_form_blueprint by noting 'create のみ' and that migrate/update for existing slugs belongs to that sibling. This is a clear verb+resource pairing with sibling differentiation.

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

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

The description gives explicit conditions: use only for creation, use apply_form_blueprint for migrate/update of existing slugs, and do not use for inquiries. It also recommends templateSlug from list_builtin_form_templates and explains how to select it via purposeLabels, providing actionable when-to-use guidance.

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

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

The description adds substantial behavioral context beyond the annotations: the dryRun contract (status/wouldSucceed/kind), the rule to only execute when dryRun returns the expected kind, the unsupported error condition (field_type_migration_blocked), idempotency conflict behavior, and the destructive clean-up scoping for archive_form_set. It does not contradict the readOnlyHint=false or destructiveHint=true annotations; it explains when destruction is acceptable.

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

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

The text is dense and long, but this is a complex tool with many edge cases. It is front-loaded with the essential required/optional parameters and the dryRun-first rule, and every sentence adds a distinct decision rule or constraint. Slightly run-on in places, but appropriate for the complexity.

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

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

Given the tool's complexity, rich schema, and existing output schema, the description covers the full decision tree: dryRun-first flow, kind-specific execution rules, unsupported type-change handling, migration to Master Reference, retry prohibitions, and cleanup scoping. Very little that an agent needs to safely invoke this tool is missing.

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

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

Since schema description coverage is 100%, the baseline is 3, but the description adds meaningful usage nuance: blueprint uses fieldKey/sortOrder rather than Contact Form's key shape, dryRun must be true first, and idempotencyKey has a 409 conflict behavior. This goes beyond the schema's field definitions and gives the agent operational semantics for the parameters.

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

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

The description clearly identifies the tool as applying a Form Blueprint, specifies the required shape (version + formSet + forms with fieldKey/sortOrder), and explicitly distinguishes it from the Contact Form { key, label:{ja,en} } format. It also names sibling alternatives (migrate_field_to_master_reference, propose_change, archive_form_set) for related workflows, making the tool's scope unambiguous.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: always run dryRun first, only proceed when the returned kind matches, use migrate_field_to_master_reference for static enum→Master Reference, avoid archive_form_set as a first option, and never retry the same slug on unsupported. This is exceptionally actionable routing for an agent.

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

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

Adds meaningful behavior beyond the destructiveHint=true annotation: publish:true has a side effect on the public master API, color has merge semantics (omit keeps existing, null clears), and the tool exists because agent keys cannot use update_master_record. No contradiction with annotations; not stating what happens to records omitted from the payload is the only notable omission.

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

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

Three dense sentences front-load required vs optional params before behavioral details, then close with doc references. Every clause earns its place, and the most decision-relevant facts (publish, ordering, color semantics, agent-key constraint) appear before the pointers to external resources.

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

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

For a destructive, schema-heavy tool with 100% schema coverage and an output schema, the description covers the operational essentials: required/optional params, publish side effects, ordering, color behavior, and the agent-key rationale, pointing to help resources for the rest. It does not state what happens to existing records omitted from the payload or describe dryRun in prose, though dryRun is documented in the schema.

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

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: it warns that record ordering depends on sort_order/sortOrder rather than array order, extends publish's effect to the public master API beyond the schema's site-reflection wording, and explains why these fields must be populated here. The color semantics are duplicated from the schema, and dryRun behavior is left to the schema.

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

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

States a specific verb and resource — "Master Blueprint を一括 upsert" (batch upsert of Master Blueprint) — and differentiates from the closest sibling by noting that update_master_record is unavailable to agent keys, so sort_order/color must be set here. The unexplained "schema/full" parenthetical introduces minor ambiguity about the operation's mode, keeping this below a 5.

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

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

Gives an explicit routing rule: because update_master_record cannot be called with an agent key, this tool is the designated place to set sort_order/color — a clear when-to-use versus a named alternative. It also specifies publish semantics (true reflects to the site and public master API; omitted means not reflected), but does not mention validate_master_blueprint as a pre-flight alternative for checking a blueprint before applying.

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

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

Annotations already mark this destructive, and the description strongly reinforces and enriches that: it is a soft-delete, requires a dryRun step, requires confirmToken, returns 400 without it, forbids agent restore, and excludes Contact Form deletion. No contradiction with annotations.

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

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

The description is dense but every sentence earns its place: scope, safety, required workflow, error conditions, exclusions, restore restrictions, and return fields. It is front-loaded with the core purpose and then layers necessary operational detail without fluff.

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

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

Given the destructive nature and multi-step workflow, the description is remarkably complete: it explains prerequisites, error codes, permission limits, return-field expectations, and edge cases, while also pointing to further docs. The output schema exists, so not describing the full return shape is acceptable.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful sequencing and consequence details beyond the schema: dryRun must happen first, confirmToken must be supplied on the real call or a 400 occurs, and formSetId must be a UUID rather than a slug. Some repetition of schema content prevents a 5.

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

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

The description clearly states the action ('archive') and resource ('Form Set'), then sharpens it: soft-delete with deleted_at, not hard delete. It also distinguishes from related operations by saying it is not for type changes, Contact Form cannot be deleted, and that human Console DELETE remains unchanged.

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

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

The description gives an explicit two-phase workflow: first call with dryRun: true to get slug/entryCount/confirmToken/restore, then pass confirmToken in the real call. It states a concrete failure mode (400 without token), says not to use it for type changes, and notes restore requires a human JWT (403 for agents), leaving no ambiguity about when and how to use this tool.

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

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

Annotations already convey readOnly/idempotent/openWorld hints. The description adds genuinely useful behavior beyond them: retry guidance for 502/truncated responses and an explicit host-LLM-dependency instability warning. No contradiction with annotations; openWorldHint=true actually aligns with the instability caveat.

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

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

Compact and front-loaded: the primary purpose leads, followed by routing and error-handling caveats. It packs a lot into a few clauses and every segment adds value, though the dense run-on structure could be cleaner.

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

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

For a moderate-complexity RAG tool with 2 params (1 required) and an output schema present, the description covers purpose, alternatives, retry behavior, and stability expectations. Nothing critical is missing for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so both parameters are already documented (question as natural-language query, locale as ja/en). The description only restates that question is required and locale optional, which is borderline redundant. Baseline 3 is appropriate since the schema carries the parameter meaning.

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

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

States a specific verb+resource: asking LUNO usage questions in natural language via RAG. It also distinguishes itself by pointing to category agents for snapshot/public API/Blueprint topics and to search_admin_help/get_admin_help_article for repeated queries, so an agent can tell it apart from closely-related siblings.

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

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

Gives explicit routing guidance: snapshot/public API/Blueprint questions go to category agents, and if the question repeats, use search_admin_help/get_admin_help_article instead. This tells the agent both when to use this tool and when to defer to alternatives.

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

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

The description discloses key behavior beyond the annotations: each item succeeds or fails independently, slug conflicts fail only the affected item, and idempotencyKey replays the entire batch. This gives the agent important expectations for partial success and retry behavior.

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

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

The description is dense and well-structured: main action first, then required/optional parameters, then behavior and alternatives. Every sentence adds distinct value with no fluff or repetition.

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

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

For a mutating bulk operation with an output schema and annotations, the description covers input requirements, limits, partial-failure semantics, idempotency, and the relationship to save_revision. An agent has enough context to call the tool correctly without guessing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning by clarifying required vs optional parameters, whole-batch idempotency semantics, and slug-only item creation. The schema already documents parameters well, but the description reinforces the most important operational nuances.

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

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

The description clearly states it bulk-creates up to 50 entries in a Form Set using only slugs, and immediately distinguishes this tool from create_entry and save_revision. The verb, resource, and scope are specific and unambiguous.

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

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

The description explicitly frames this as a replacement for N×create_entry and directs body content to save_revision. It also warns that bulk deletion is not available, giving the agent clear guidance on when to use this tool and when to choose alternatives.

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

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

The description adds substantial behavioral context beyond the annotations: dryRun semantics, slug collision behavior with specific status codes, idempotencyKey conflict and expiry, no-deletion constraint, and a documentation pointer. It also explains that fields use a different shape than Form Set fieldKey, which is critical for correct invocation.

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

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

The description is dense and front-loaded with the core purpose, but it is a single run-on block with many semicolon-separated instructions. It stays reasonably compact given the complexity of the tool, and every clause contributes useful information, though clearer structuring would improve scannability.

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

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

For a tool with 11 parameters, nested objects, and an output schema, the description covers essential operational context: prerequisites, dryRun-first workflow, collision handling, idempotency caveats, and exclusions of related tools. The existence of an output schema means return-value documentation is not required here, and the pointer to agent.contact-form-mcp fills remaining gaps.

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

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

Schema coverage is 100%, so the schema already documents every parameter individually. The description adds meaningful layer on top: which parameters are required, which are optional groups, that dryRun must be true first, and that fields must NOT use the Form Set fieldKey shape. This exceeds the baseline for fully covered schemas.

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

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

Description clearly identifies the action: creating a new Contact Form, and specifies the resource scope with 'Contact Form を新規作成'. It also distinguishes itself from Form Set templates and apply_form_blueprint, which helps an agent separate this tool from related siblings.

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

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

Provides an explicit workflow: run dryRun: true first, check status/wouldSucceed, then execute. It names the tools and approaches not to use, states required fields to ask the user for, and warns against retrying the same slug. This is strong practical guidance.

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

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

Beyond the idempotentHint annotation, the description explains idempotencyKey behavior in practical terms: same key resend returns same id, different args cause 409 conflict, and keys expire after 24 hours. It also discloses that the entry body is not included, which is important behavioral context.

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

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

The description is a single dense paragraph that front-loads the core action, then lists required/optional parameters and the follow-up sequence. Every sentence carries necessary information with no filler.

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

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

For a creation tool with a rich input schema and an output schema, the description covers the essential agent-facing context: required fields, optional idempotency semantics, the fact that no body is sent, the expected production workflow, and how to use the returned id.

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

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

Schema description coverage is 100%, and the schema already documents formSetId as a UUID, slug as the new entry slug, and idempotencyKey semantics. The description mostly reinforces this information rather than adding substantial new parameter meaning, so baseline 3 is appropriate.

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

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

The description clearly states a specific action ('エントリを新規作成') and immediately clarifies that the body is not included, distinguishing this from body-related tools like save_revision/update_entry. It also names the exact follow-up workflow, leaving no ambiguity about what this tool does.

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

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

The description provides clear context: it creates an entry without a body and must be followed by save_revision → get_pub_preview_url → publish_revision. It explicitly lists required and optional parameters, but does not directly contrast with bulk_create_entries or other sibling creation tools.

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

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

Annotations already convey that this is a non-read-only, non-idempotent operation, and the description mainly restates 'create' plus a parameter summary. It adds no extra behavioral context such as side effects, permission requirements, uniqueness constraints, or response semantics, so the value beyond annotations is minimal.

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

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

The description is compact, front-loaded with the action, and easy to scan. The phrase 'content 可' is slightly ambiguous, but the overall structure is efficient and free of filler.

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

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

For a creation tool with a fully documented input schema and an output schema, the description covers required vs optional fields and the relevant alternative for bulk operations. It does not explain what the API returns, but the output schema handles that responsibility.

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

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

Schema coverage is 100%, so the schema already documents every parameter. The description usefully repeats required vs optional and flags the label locale-map possibility and #RRGGBB format, but it does not add much meaning beyond the schema.

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

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

The description opens with 'マスタレコードを新規作成' (create a new master record), naming the exact action, resource, and the fact that this is a creation operation. It also distinguishes itself from bulk workflows by pointing to apply_master_blueprint for ordering and color.

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

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

The description explicitly routes agents to apply_master_blueprint when the goal is bulk ordering/color ('並び・色の一括投入は apply_master_blueprint 推奨'). It doesn't explicitly contrast with update_master_record, but '新規作成' makes the primary use case clear enough.

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

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

Annotations already communicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description aligns with this by stating deletion, and adds useful context about the Business+ plan requirement and the need for a ruleId from the list operation. However, it does not go beyond that to describe consequences, error behavior, or reversibility, so it neither contradicts nor substantially enriches the behavioral profile.

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

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

The description is a single compact sentence that front-loads the action and resource, then states the essential requirement. Every word contributes: the plan level, the action, the resource, and the parameter source. No filler or redundancy.

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

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

For a one-parameter destructive tool, the description covers the action, the source of the required parameter, the plan prerequisite, and the safety profile is covered by annotations. An output schema exists, so return values need no explanation. Sibling tools for listing and adding are present, and the description effectively disambiguates the input source. Nothing essential is missing.

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

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

The input schema already documents ruleId as a UUID with description '許可ルール UUID', so schema coverage is 100%. The description adds meaningful semantics by specifying that the ruleId is the id from list_console_login_ip_allowlists, which instructs the agent where to source the value. This goes beyond the schema and justifies a score above baseline.

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

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

Description states the specific action '削除' (delete) on a clear resource '管理画面ログイン IP 許可ルール' (admin console login IP allow rule), and includes a plan qualifier (Business+). It clearly differentiates from sibling tools like add_console_login_ip_allowlist by being the delete counterpart, and references list_console_login_ip_allowlists for obtaining the ID.

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

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

The description explicitly states the mandatory prerequisite: ruleId must be the id from list_console_login_ip_allowlists. This gives clear contextual guidance on how to obtain a valid parameter value. It does not explicitly mention when not to use the tool or compare with add_console_login_ip_allowlist, but for a simple delete tool this is sufficient.

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

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

Annotations already indicate this is a mutating, non-idempotent operation. The description adds that the run receives a terminal status and returns metrics, which is useful. However, it does not disclose potential side effects, whether the action is reversible, or clarify the meaning of the parenthetical 'schema/full'.

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

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

The description is concise and front-loaded with the primary action and required parameters. The 'schema/full' phrase is ambiguous and unexplained, which slightly detracts from clarity, but overall the structure is efficient and every sentence contributes useful information.

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

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

For a tool with only two required parameters and an output schema, the description covers the essential information: what the tool does, required inputs, the source of the run ID, accepted statuses, and the return value. It is adequately complete for invocation, though a bit more detail about side effects or error conditions would improve it.

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

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

Schema coverage is 100% and both parameters have descriptions. The tool description adds meaningful value by explicitly directing users to pass start_agent_run's agentRun.id property, which is more precise than the schema's 'Agent run id from start_agent_run'. The status enum values are repeated but that is redundant with the schema.

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

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

The description states a specific action and resource: 'Agent Run を終了' (terminate an Agent Run). It also mentions the terminal statuses and the requirement to pass the run ID, clearly distinguishing it from start_agent_run and get_agent_run.

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

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

The description gives clear usage context by requiring the agentRun.id from start_agent_run and specifying the terminal statuses. It does not explicitly say when not to use the tool, but the prerequisite is clear enough for an agent to know this is the completion step for a started run.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns the article body, but this is more purpose than additional behavioral context such as pagination, error conditions, or output format.

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

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

The description is a single focused sentence, front-loaded with the core behavior, followed immediately by the required parameter and examples. There is no wasted text.

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

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

This is a simple single-parameter read operation with an output schema and annotations already covering safety and idempotency. The description provides the essential usage detail (where the ID comes from) and examples, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents articleId. The description adds value by specifying the ID must come from search_admin_help and providing realistic examples (content.publish-workflow, agent.publish-revision), which helps the agent supply a valid value.

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

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

The description clearly states a specific verb and resource: it retrieves the body of a single admin help article. It distinguishes itself from search_admin_help (which finds articles) and ask_admin_help (which likely answers questions) by specifying that articleId comes from search_admin_help.

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

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

The description explicitly names the required parameter and tells the agent to obtain articleId from search_admin_help, with concrete examples. It implies the correct usage pattern but does not explicitly contrast with alternatives like ask_admin_help.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the ownership/authorization restriction ('自分が開始した run のみ（他キーは 403）') and the 'schema/full' output distinction, which go beyond the annotations and inform call behavior.

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

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

The description is a compact, single-line set of clauses with no filler. The core purpose is front-loaded, followed by the required parameter and the key access constraint. Every phrase earns its place.

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

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

Given the fully documented input schema, the presence of an output schema, and annotations covering safety and idempotency, the description adds the crucial ownership restriction and output variant. Nothing essential is missing for an agent to call this tool correctly.

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

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

Schema coverage is 100% and the runId parameter already has a rich description in the schema, including its source (start_agent_run response agentRun.id). The tool description's '必須: runId' merely repeats the schema's required array and adds no new parameter meaning.

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

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

The description uses a specific verb ('取得' – get) and resource ('Agent Run の状態・メトリクス'), clearly distinguishing it from mutating siblings like start_agent_run and end_agent_run. It also identifies the required runId and the 'schema/full' output variant, making the tool's scope unambiguous.

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

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

It provides clear context: the call requires a runId, and only runs started by the caller are accessible; other runs return 403. It does not explicitly name alternative tools or state when not to use it, but the retrieval purpose is evident against its mutating siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior. The description adds meaningful context beyond annotations: access is restricted to self-proposed plans, and state-changing actions like approval/rejection/execution are outside this tool's scope. This helps prevent misuse without contradicting the annotations.

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

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

The description is compact and front-loaded, with the main action stated first. The parenthetical 'schema/full' is slightly ambiguous, but it does not significantly detract from overall clarity and every other part earns its place.

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

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

For a simple read tool with one parameter, full schema coverage, an output schema, and safe annotations, the description provides all necessary operational context: parameter source, access restriction, and human-console boundary. Nothing needed for correct invocation is missing.

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

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

Schema coverage is 100%, and the schema already specifies format and UUID constraints. The description adds value by clarifying that planId must come from the changePlan.id returned by propose_change, establishing provenance beyond the schema.

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

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

Description clearly states the tool retrieves the status of a Change Plan, with the specific resource and verb. It also clarifies scope boundaries (own plans only) and distinguishes this read operation from approval/rejection/execution actions performed via Human Console, making it distinguishable from related workflow tools.

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

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

Provides explicit usage guidance: requires planId obtained from propose_change response, only works for plans the caller proposed, and approval/rejection/execution must be handled through Human Console. This tells an agent when to use the tool and when not to use it.

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

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

Annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no behavioral context beyond the singular resource and required parameters, but it also does not contradict the annotations.

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

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

The description is extremely short, with no filler words, and places the key requirement in the second clause. It is efficient structurally, though it borders on under-specification.

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

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

For a simple read-by-ID tool, the schema, output schema, and annotations cover most operational details. However, the description itself does not explicitly state the action or distinguish it from list_entries, so it is only minimally viable on its own.

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

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

Schema description coverage is 100%, and the schema already explains where each UUID can be obtained, including that formSetId is not a slug. The description merely repeats the required parameter names and the UUID type without adding semantic value.

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

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

The description identifies the resource as one entry (「エントリ 1 件」) and the required IDs, but it is a noun phrase with no explicit verb such as 'get' or 'retrieve'. It also does not contrast with the sibling list_entries, so the agent must infer the operation largely from the tool name.

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

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

No guidance is given about when to use this tool versus alternatives like list_entries. The only additional statement is that formSetId and entryId are required, which duplicates schema information and provides no usage context or exclusions.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows this is a safe read. The description adds useful context about the enriched schema content and the pre-save verification requirement. It does not explain error behavior or what happens if formSetId is invalid, but the annotation coverage lowers the burden.

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

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

The description is compact and front-loaded: the core purpose (schema + snapshotShape for save_revision) comes first, followed by the critical usage warning. The enrichment detail for select/radio/multiselect is dense but relevant and efficiently expressed. No wasted words.

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

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

For a low-complexity, read-only, idempotent tool with a full output schema and one well-documented parameter, the description covers the key caveat (check before saving) and parameter origin. Minor gaps are explicit sibling differentiation and error scenarios, but these are not critical given the annotations and schema richness.

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

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

Schema description coverage is 100% and the schema already clearly describes formSetId as a UUID from list_form_sets / apply_* responses, not a slug. The description reinforces this by repeating the requirement and marking it as '必須', but adds little beyond the schema's own parameter documentation. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: fetching one Form Set's schema plus snapshotShape for save_revision. It also specifies that select/radio/multiselect fields are enriched with masterEntityKey, sampleValues, and public record URLs. It is clear and resource-specific, though it does not explicitly contrast itself with sibling get_* tools like get_tenant_schema.

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

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

The description explicitly says '保存前に必ず確認する' (always check before saving), indicating when this tool should be used. It also clarifies the required parameter formSetId must be a UUID from list_form_sets / apply_* responses, not a slug, which is essential usage guidance. However, it does not name alternatives or say when not to use this tool.

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

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

The description's verb '再構成' implies a state-changing operation, contradicting the annotations readOnlyHint=true and idempotentHint=true. Besides this contradiction, it adds no behavioral context such as what data is returned or what the fallback does.

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

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

The description is short and mentions the parameter; however, the primary sentence is semantically wrong and the pointer '詳細: agent.measurement-funnel' is vague. The brevity is not supported by accurate content.

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

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

Although an output schema exists, the description does not define what 'funnel status' means, when to call this tool, or why it exists in the MCP measurement domain. The misleading verb leaves an agent without enough context to call it correctly.

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

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

The schema already covers the single funnelId parameter and its UUID format. The description adds the useful fallback semantics '省略時は当セッション / LUNO_FUNNEL_ID', specifying an environment-variable fallback not present in the schema description.

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

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

The description says the tool '再構成' (reconfigures/reconstructs) the MCP Private Beta measurement funnel, which is a mutating verb and does not state that the tool gets/returns funnel status. It names a resource but not the correct operation, and it provides no differentiation from sibling read tools like get_project_overview or get_agent_run.

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

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

There is no guidance on when to use this tool or which alternative to prefer. The only usage-related content is the optional funnelId fallback, but no conditions, prerequisites, or comparison with sibling tools are given.

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

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

The annotations already mark this as read-only, idempotent, and non-destructive; the description adds useful context beyond them by noting that authentication is required and that availability depends on plan level (Standard+ for background, Business+ for WL). No contradiction with the annotations exists.

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

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

The description is a single compact sentence with no filler. The most important facts—what it does, authentication, and no arguments—are front-loaded, and the plan-related restriction is appended concisely.

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

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

For a zero-parameter read-only tool with an output schema and safety annotations, the description covers the key prerequisites and plan constraints. It is slightly incomplete because 'WL' is left unexplained and the relationship to get_login_branding is not addressed, but these are minor gaps given the low complexity.

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

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

There are no parameters and the schema coverage is 100%, so the schema already fully defines the input surface. The description reinforces this by explicitly stating '引数なし' (no arguments), which is helpful but adds little beyond the empty schema.

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

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

The description clearly states the verb '取得' (retrieve) and the resource '管理画面ログインの見た目設定' (admin console login appearance settings), making the core purpose unambiguous. However, it does not differentiate this tool from the sibling get_login_branding, which appears closely related.

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

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

The description gives useful operational prerequisites: authentication is required and no arguments are needed. It does not state when to prefer this tool over get_login_branding or update_login_appearance, and it does not mention any exclusions or alternatives.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds the no-authentication requirement and the default project behavior, which are useful behavioral traits not present in annotations.

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

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

The description is a single compact sentence that front-loads the purpose, then states the optional parameter and the returned fields. No redundant filler.

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

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

With annotations, full schema coverage, and an output schema, the description is nearly complete for invoking the tool. It only misses an explicit comparison to get_login_appearance, which could affect tool selection among siblings.

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

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

Schema description coverage is 100% and the only parameter (projectId) is already described as optional with the same default-project semantics. The description repeats this information without adding new detail, so it stays at the baseline.

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

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

The description clearly states it retrieves admin-console login branding and lists the returned fields (branding_tier, login_background, hide_*). It does not distinguish itself from the similarly named sibling get_login_appearance, so it falls short of full sibling differentiation.

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

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

States that no authentication is required and that projectId defaults to the agent key's project, giving clear context for when to call it. It does not explicitly mention alternatives or when not to use it, especially given the similar get_login_appearance sibling.

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

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

Annotations already set readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only behavior is fully covered by annotations. The description adds that this returns a single master entity, but doesn't disclose anything beyond that, such as potential 404 behavior or locale handling, which is a modest addition over annotations.

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

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

One concise sentence that front-loads the resource and required parameter, but it is terse enough that it omits any mention of the response shape or error behavior.

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

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

With output schema available and a single parameter fully documented in the schema, the description covers the essential calling context. The gap is minimal—no mention of which sibling provides the ID—but the reference to list_master_entities partially fills that.

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

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

Schema description coverage is 100%, so the schema already explains entityId as a UUID from list_master_entities. The description repeats that same information without adding new meaning, which is acceptable but not additive.

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

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

The description states a specific resource ('マスタエンティティ 1 件') with a concrete verb and the key parameter. It clearly distinguishes this from sibling list_master_entities by indicating it retrieves a single entity by ID.

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

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

It indicates a required parameter (entityId) and references list_master_entities as the source of that id, which implies when to use it, but it does not explicitly state when not to use it or mention alternatives like list_master_records.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds valuable behavioral context beyond them: it discloses that the tool does not call the LUNO API (network behavior), that the host API may be undeployed (availability), and that a 404 response signals an outdated API (error interpretation). It also warns against mutation attempts. This substantially enriches the agent's understanding.

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

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

The description is two sentences, front-loaded with the core purpose and fields, followed by critical caveats (deployment, error code, mutation warning). Every sentence contributes value with no fluff. The structure is efficient and easy to parse.

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

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

The tool is simple (no parameters), has an output schema (not shown but present), and annotations cover safety. The description adds the remaining needed context: error handling (404), deployment state, and the no-mutation constraint. Nothing an agent needs to call this correctly is missing.

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

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

The tool has zero parameters, and the schema is empty. The description redundantly confirms '引数なし' (no arguments), which matches the schema. Since there are no parameters to document, the baseline of 4 applies; the description does not need to add parameter-specific meaning beyond confirming the absence of arguments.

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

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

The description states a specific verb and resource: 'runtime information for this MCP package'. It explicitly lists the returned fields (mcpVersion, toolCount, contract) and clarifies it does not call the LUNO API, distinguishing it from sibling tools that interact with APIs. This is unambiguous and specific.

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

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

The description provides usage context: it notes the tool takes no arguments, warns that the host API may not be deployed even if the tool is loaded, and explains that a 404 indicates an outdated API. It also advises against inventing alternative mutations, which is a clear exclusion. However, it does not explicitly name alternative tools, though the tool's unique purpose makes selection obvious.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by stating there are no arguments and by naming the specific returned settings: enabled/disabled, content_locales, and content_default_locale.

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

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

The description is a single concise sentence with the main action and resource front-loaded, followed by the relevant output fields. There is no filler or repeated information from the schema.

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

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

For a parameterless getter with full annotation coverage and an output schema available, the description provides sufficient context. The resource, behavior, and returned fields are all indicated, and the structured metadata covers safety, idempotence, return values, and schema details.

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

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

There are zero parameters, so the description has little to explain. It explicitly states '引数なし' (no arguments), which reinforces the empty input schema and removes any doubt about invocation requirements. This matches the baseline of 4 for parameterless tools.

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

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

The description clearly states the verb '取得' (get) and the resource 'サイトのコンテンツ多言語設定' (site content multilingual settings), and it lists the relevant output fields. It is specific and easy to understand, though it does not explicitly differentiate itself from sibling tools like patch_project_content_locales.

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

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

The description implies this is the read-only counterpart to patch_project_content_locales, but it does not explicitly state when to choose this tool versus alternatives. The '引数なし' note is helpful for invocation, but the description does not provide when-to-use or when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations: it returns available:false on insufficient permissions, warns not to drop Contacts into Form Set templates even for empty projects, and clarifies that the MCP package version differs from the API contract. This is useful non-obvious behavior.

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

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

The description is dense but front-loaded with the primary use case ('既存プロジェクト再開時の最初の一手') and packs a lot of routing and behavioral information into a compact space. It is somewhat long and mixes multiple concerns, but every sentence earns its place; a 4 is appropriate.

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

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

For a zero-parameter read-only tool with an output schema, the description is complete: it lists the major payload sections, notes the permission-failure behavior, warns about a common misuse (Contact to Form Set template), and routes to get_mcp_runtime and agent.discover for related concerns. Nothing needed to call it correctly is missing.

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

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

The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameter meaning. The baseline for 0 params is 4, and the description appropriately focuses on return payload semantics instead.

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

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

The description states a specific verb and resource: it returns a project overview for resuming existing projects, listing intentCapabilities, nextMoves, hints.intent, Form Sets, Contact Forms, Masters, quota, locales, and public API base. It also distinguishes itself from get_mcp_runtime and points to agent.discover for details, so an agent can tell it apart from siblings.

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

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

The description explicitly says when to use it: '既存プロジェクト再開時の最初の一手' (the first step when resuming an existing project). It also names alternatives: create_contact_form for inquiries, purposeLabels/templateSlug for notices/blogs, and get_mcp_runtime for MCP package vs API contract. This is clear routing guidance with exclusions.

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

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

Beyond the annotations, which already indicate a safe read-only and idempotent operation, the description discloses the important environment-specific behavior: locally it returns /public/p/{projectId}/v1, and the host-based /public/v1 falls back to DEFAULT_TENANT_ID. This is valuable behavioral context not present in the structured annotations.

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

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

The description is two short sentences with no filler. It front-loads the core purpose, then adds the necessary local-environment nuance in the second sentence, earning its place.

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

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

For a zero-parameter read-only tool with annotations covering safety and an output schema present, the description is complete. It tells the agent what the tool returns, that no arguments are needed, and how the URL differs in local contexts. Nothing critical is missing.

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

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

The schema has zero parameters and the description explicitly confirms '引数なし' (no arguments). Since there are no parameters to describe, the baseline is appropriately 4; the description reinforces the schema rather than adding new parameter-level meaning.

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

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

The description clearly states the tool's function: it returns the public API base URL for the agent key's project. It also specifies that it takes no arguments, making the tool's scope unambiguous and distinct from other URL-related tools like get_pub_preview_url.

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

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

The description provides clear context by explaining the local versus host-based URL behavior and explicitly stating that no arguments are required. It does not explicitly name alternative tools or when-not-to-use conditions, but for this simple no-parameter utility, the usage context is sufficient.

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

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

Annotations already convey read-only/idempotent/non-destructive behavior. The description adds behavioral context beyond those flags: the POST method, the human-browser confirmation step, the Standard+ plan requirement for unpublished content, and the subsequent can_publish=false path. There is no contradiction with annotations.

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

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

The description is compact and front-loaded: purpose first, then required params, optional param, usage of the result, next-step workflow, plan note, and reference. Every clause carries necessary information and there is no filler or restatement of the tool name.

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

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

For a read-only preview tool with a rich output schema, this covers all call-time needs: required and optional parameters, target behavior, plan prerequisite, and what to do after obtaining the URL. Nothing needed to invoke the tool correctly is missing.

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

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

Schema description coverage is 100% and the parameter descriptions already phrase the required fields and target enum meanings in detail. The tool description restates required vs optional parameters and the target default, but adds little semantic value beyond the schema, so the baseline 3 applies.

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

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

The description opens with a specific action and resource: '下書き/承認待ちリビジョンのプレビュー URL を取得' and names the POST pub-preview-url endpoint. It clearly differentiates the tool from publish_revision by framing this as the preview step before publication.

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

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

It provides strong workflow context: which IDs are required (including revisionRowId from save_revision), the optional target choices, the instruction to open the returned URL in a browser, and the follow-up publish_revision flow with can_publish=false handling. It lacks an explicit when-not-to-use or alternative-tool exclusion, so it stops short of a 5.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive, and the description does not contradict them. The description adds useful behavioral context by indicating this is a bulk retrieval of form set and field definitions for the operating project, which goes beyond the structured hints.

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

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

The description is a single short sentence with the action front-loaded and the no-argument requirement clearly stated. Every word earns its place and there is no unnecessary detail.

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

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

For a parameterless, read-only tool with an output schema, the description is complete enough for an agent to call it correctly. It states the resource scope, the fact that no arguments are needed, and the annotations cover the safety profile.

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

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

The tool has zero parameters and schema description coverage is 100%, so the schema fully defines the input surface. The description's 引数なし reinforces the empty schema but adds no further needed parameter-level meaning, which is acceptable given the baseline for no-parameter tools.

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

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

The description uses a specific verb (一括取得する) and identifies both the resource (form set/field definitions) and scope (current project). It is clear what the tool does, though it does not explicitly differentiate itself from sibling tools like get_form_set_schema.

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

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

The description gives no guidance on when to use this tool versus alternatives such as list_form_sets or get_form_set_schema. It only states the current-project scope and that there are no arguments, so an agent must infer selection criteria.

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

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations: it takes no arguments, returns slugs to be consumed by another tool, warns against memorizing slugs, and clarifies that contact-form functionality is intentionally absent. This goes beyond the structured metadata without contradicting it.

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

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

The description is compact, front-loads the tool's identity and argument requirement, and every sentence adds actionable value: matching strategy, output usage, anti-memorization guidance, and exclusion routing. The pointer to 'agent.builtin-form-templates' is a concise reference rather than clutter.

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

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

Given that the tool has no parameters, a read-only/idempotent annotation profile, and an output schema, the description covers all necessary context: what the list contains, how to select an item, how to use the returned slug, and where to go for contact-form needs. There are no obvious missing details that would prevent correct invocation.

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

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

The input schema has zero parameters and 100% schema description coverage, so there is nothing for the description to clarify about parameter semantics. The description still reinforces that the tool takes no arguments ('引数なし') and explains how the returned value is meant to be used, which is sufficient for this parameter-less tool.

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

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

The description clearly identifies the tool as a no-argument list of official LUNO Form Set starters, and explains that its purpose is to match use cases via purposeLabels and return slugs for use with apply_builtin_form_template. It also distinguishes itself from create_contact_form by stating that contact forms are not included here.

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

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

It explicitly tells the agent when to use this tool: to fetch built-in form templates, match by purposeLabels, and pass the returned slug to apply_builtin_form_template.templateSlug. It also gives a clear exclusion — contact forms are not here, use create_contact_form or get_project_overview.intentCapabilities instead — so the agent knows when NOT to use this tool.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a 'Business+' plan requirement, which is useful, but otherwise adds no behavioral context beyond what annotations and the empty schema already communicate.

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

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

The description is a single compact phrase that conveys the resource, action, plan restriction, and argument status with no filler. It is appropriately front-loaded and every element earns its place.

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

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

For a simple, zero-argument, read-only list operation, the description along with the annotations and output schema covers everything an agent needs to invoke it correctly. No return-value details are needed because an output schema is present.

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

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

The tool has zero parameters and schema_description_coverage is 100%, so parameter ambiguity is nearly nonexistent. The description explicitly states '引数なし' (no arguments), reinforcing the empty input schema with a useful confirmation.

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

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

The description clearly names the resource ('管理画面ログイン IP 許可リスト') and indicates the list action ('一覧'), with useful qualifiers for plan and arguments. It is unambiguous, but it does not explicitly differentiate itself from sibling tools such as get_login_branding or other list operations.

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

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

The description implies that this tool is for retrieving IP allowlists, rather than adding or deleting them via the sibling add/delete tools. However, it does not provide explicit when-to-use guidance, exclusions, or mention of alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful behavior that returned item.id should be used as entryId, but does not disclose pagination, sorting, or result limits. With existing annotations, this is adequate but not rich.

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

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

The description is two short, front-loaded sentences with no redundant content. It states the purpose, the required parameter, and the key integration hint about item.id without wasted words.

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

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

For a single-parameter list operation with an output schema and safety annotations, the description is complete. It covers what the tool does, the required input, and how the response should be consumed, leaving no critical gap for correct invocation.

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

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

Schema description coverage is 100%, and the schema already documents formSetId as a required UUID with detailed source context. The description repeats '必須: formSetId（UUID）' without adding new parameter-level meaning, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Form Set 内のエントリ一覧' (list entries in a Form Set). This clearly distinguishes it from sibling tools like list_form_sets (lists Form Sets) and get_entry (retrieves a single entry).

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

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

The description gives clear contextual usage: list entries within a Form Set, requires formSetId, and tells the agent to use the returned item.id as entryId for downstream operations. It does not explicitly mention when not to use it or name alternatives, but the guidance is sufficient for typical selection.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so no side-effect warning is necessary. The description adds useful behavioral context: there are no arguments, and the returned ids are UUIDs intended for formSetId fields rather than slugs. This goes beyond what the annotations alone provide.

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

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

The description is extremely concise: two short Japanese sentences with no filler. The core action is front-loaded, and the second sentence adds essential actionable guidance about the returned IDs.

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

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

Given zero parameters, an existing output schema, and annotations covering safety, the description is complete. It tells the agent exactly what the tool does and how to use the results, leaving no critical operational gap for a simple list operation.

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

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

There are zero parameters and an empty input schema, so the parameter burden is already fully covered by the schema. The description explicitly confirms '引数なし' (no arguments), matching the schema and leaving no ambiguity.

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

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

The description states a specific action and resource: 'Form Set 一覧を取得する' (retrieve the list of Form Sets). It also clarifies that each item's id is a UUID to be used as formSetId, which helps distinguish this listing tool from other form-set-related tools. It does not explicitly name sibling tools, but the listing purpose is unambiguous.

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

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

The description gives clear downstream usage guidance: use each returned id (UUID) as formSetId in other tools, and avoid using the slug. This context implicitly tells the agent when this tool is needed. It does not explicitly state exclusions or alternatives, but the guidance is sufficient for a zero-argument list tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context by noting that the list includes key, hierarchical, and record_count fields and that item.id should be used as entityId, but it does not mention pagination or list-size behavior; the presence of an output schema reduces the need for return-format details.

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

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

The description is two compact sentences with no filler. The purpose is front-loaded, and the parenthetical clarifies the no-argument constraint and included fields, while the final clause adds a practical integration note.

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

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

For a no-argument, read-only list tool with an output schema and safety annotations, the description is nearly complete. It could be slightly clearer about how this relates to sibling tools or where the entityId hint is meant to be used, but those are minor gaps for such a simple operation.

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

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

The tool has zero parameters, and schema description coverage is 100%. The description reinforces this with '引数なし' (no arguments), which is sufficient; there are no parameter semantics to elaborate.

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

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

The description clearly identifies the resource as 'マスタエンティティ一覧' (master entity list) and states the operation is a list with no arguments. It does not explicitly differentiate from siblings like list_master_records, but the master-entity focus and the included fields make the purpose reasonably clear.

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

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

There is no guidance on when to choose this tool over alternatives such as list_master_records or get_master_entity. The note 'item.id を entityId に使う' gives a downstream usage hint, but it does not explain selection conditions or exclusions.

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

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

Annotations already cover safety with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful response semantics: 'label は locale map' and '階層時は parent_record_id' explain how fields behave, but it does not disclose pagination, ordering, or any result-set limitations.

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

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

The description is a single compact line that front-loads the core purpose and packs two useful field hints into a parenthetical. Every element carries meaning, with no redundant wording.

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

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

The required parameter, optional search, and key response quirks are all present. With an output schema and safety annotations available, nothing critical is missing, though adding a brief note about when to choose this over list_master_entities would improve completeness.

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

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

Schema description coverage is 100%, and the description's mention of required/optional parameters simply repeats the schema. It adds no new meaning for entityId or q beyond what the schema already provides.

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

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

The description 'マスタレコード一覧' clearly indicates a list operation on master records, with a specific resource. It distinguishes from siblings by naming 'master records' rather than 'master entities' (list_master_entities), but it does not explicitly name alternatives or contrast with other list/get tools.

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

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

The description provides no guidance on when to use this tool versus alternatives such as list_master_entities or get_master_entity. It only states that entityId is required and q is optional, leaving the agent to infer selection from the tool name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral disclosures such as pagination behavior, ordering, or whether file contents are included, but it does not contradict the annotations.

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

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

The description is a single concise sentence that front-loads the core purpose and includes the only optional parameter. There is no redundant or unnecessary content.

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

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

Given the low complexity, one optional parameter, existing output schema, and rich annotations covering safety and idempotency, the description is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, and the description only restates the limit parameter's range and default already present in the schema. It adds no new meaning beyond the structured definition.

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

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

The description clearly identifies the resource as 'uploaded media (assets)' and the operation as listing them. It is unambiguous, though it does not explicitly distinguish itself from sibling list tools like list_entries or list_form_sets.

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

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

The intended use is implied by the resource name and description, and the optional limit parameter is documented. However, it does not explicitly state when to choose this tool over alternatives or provide exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a useful integration detail (each item's id/revision goes to publish_revision), but it does not disclose behavioral details such as ordering, scope of revisions returned, pagination, or filtering. With annotations present, the bar is lower, and this modest extra context earns a 3.

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

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

The description is a single, compact sentence that front-loads the core purpose and then provides the required identifiers and downstream usage. Every clause earns its place with no redundancy or filler.

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

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

The tool is simple, has a complete output schema, and its annotations cover safety semantics. The description specifies the required parameters and the purpose of the returned values, making it fully sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, with both formSetId and entryId already fully documented in the input schema. The description only repeats that they are required and does not add additional parameter meaning beyond the schema.

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

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

The description clearly states the action: listing revisions of an entry, with a specific resource scope (an entry identified by formSetId and entryId). It also distinguishes itself from sibling tools by noting the revision ids are meant to be passed to publish_revision, differentiating it from save_revision and publish_revision.

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

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

The description provides clear context for when to use the tool: when you need revision items for an entry and intend to pass their id/revision to publish_revision. It implies a workflow but does not explicitly state when not to use it or mention alternatives such as save_revision, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces and extends this: it discloses dryRun:true-only enforcement, auto-suggest behavior for mapping, the mapping_ambiguous result, the JSONB-string caveat for constraints, that snapshot values become Master values on success, and that frontend hardcoded comparisons are a separate change. This is rich behavioral context well beyond the annotations. No contradiction.

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

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

The description is dense and front-loaded with the core purpose and required parameters, and every sentence carries real information. It is, however, on the longer side and mixes Japanese and English, with some redundancy between the main description and the schema-level description. The length is largely justified by the tool's complexity, but it could be tightened slightly.

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

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

For a tool with nested objects (mapping), 6 parameters, and subtle automation behavior, the description is remarkably complete: it covers required vs optional params, error cases (dryRun rejection, mapping_ambiguous), edge cases (JSONB string), execution path, auto-suggest behavior, snapshot implications, and help references. The existence of an output schema means return values need no explanation.

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

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

Schema description coverage is 100%, yet the description adds disambiguation that prevents common errors: formSetSlug is NOT the formSetId UUID, fieldKey is NOT the Contact Form key, mapping values are string values and NOT master record UUIDs or {from, to} objects, and formKey can be omitted when fieldKey is unique. This goes beyond what the schema's parameter descriptions provide.

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

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

States a specific verb and resource: migrating static enum (constraints.enum) to Master Reference (masterEntityKey), and explicitly frames it as a preview (schema/full). It distinguishes itself by explicitly naming the tools it is not (apply_form_blueprint / update_field / update_field_type), so an agent can tell it apart from sibling tools. The core operation is unambiguous.

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

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

Gives explicit when/when-not guidance: it never writes, execution must go through propose_change(action: migrate_field_to_master_reference), and dryRun:false or omitted is rejected without calling the API. It names alternatives to avoid (apply_form_blueprint / update_field / update_field_type) and points to get_form_set_schema for verification. No inference is left to the agent.

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

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

Annotations already convey readOnly=false, destructiveHint=true, and idempotentHint=true. The description adds valuable behavioral context by stating the authentication requirement (tenant_admin JWT only, agent key not allowed), which is not present in the annotations. It does not contradict the annotations, and the auth constraint meaningfully supplements them.

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

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

The description is a single compact sentence that front-loads the action and the auth restriction before listing the optional parameters. Every segment earns its place, with no filler or redundancy.

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

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

Given the presence of an output schema, full schema description coverage, and annotations covering mutability/destructiveness/idempotency, the description is nearly complete. The auth restriction is an important additional context signal. The main missing piece is explicit guidance on how this tool relates to sibling content-locale tools.

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

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

Schema description coverage is 100%, so the input schema already documents all three parameters with Japanese descriptions. The tool description merely lists the parameter names and marks them optional, adding little semantic value beyond what the schema already provides.

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

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

Description states the action (更新/update) and the target resource (サイトのコンテンツ多言語設定), making the tool's purpose clear. It does not explicitly contrast with sibling tools such as get_project_content_locales, so it falls just short of full sibling differentiation.

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

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

The description clearly restricts usage to tenant_admin JWT and explicitly excludes agent keys, which is strong usage boundary information. However, it does not state when to use this tool versus alternatives like get_project_content_locales for reading or translate_entry_locales for entry-level translation, leaving some routing to the agent.

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

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

Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden. It clearly states mutations are NOT executed, that the plan sits in pending_approval until a Human approves in Console, and that dry_run outputs are stored verbatim but not re-run. It lacks explicit side-effect details (e.g., audit events or rate limits), but the pending-approval and no-execution behavior is the critical disclosure and is well covered.

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

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

The description is dense but purposeful: it front-loads the core purpose and requirements, then gives the critical usage workflow, then the actionable list. Every sentence earns its place; the only slight inefficiency is the repetition of the action enum already present in the schema's enum.

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

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

The description covers goal, requirements, workflow, non-execution semantics, approval status, and cross-references to detailed docs. With an output schema present and 100% parameter coverage, this is complete for an agent to invoke the tool correctly. The steps.dry_run and mutation.body relationship, which is the trickiest part, is explicitly spelled out.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains how steps[].dry_run.raw relates to prior apply_* dryRun calls, that mutation.body is the execution payload for Human approval, and that dryRun must be absent/false at execution time. It also maps the action enum to the sibling tools. This is a clear value-add over the schema's meager property descriptions.

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

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

The description opens with a precise action: proposing multi-step structural changes as a Change Plan, scoped to schema/full, and lists the exact required constraints (goal, risk, steps with dry_run + mutation.body). It also names the five supported action types, making the tool's role unambiguous and distinguishable from the apply_* siblings.

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

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

The description explicitly states when to use it: after calling apply_* / migrate_field_to_master_reference / rename_master_record_slug with dryRun: true, and instructs how to populate steps[].dry_run.raw and mutation.body. It also clarifies that this tool does not execute mutations, which differentiates it from the executor siblings.

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

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

Beyond the annotations, the description reveals important state-transition behavior: the server absorbs the intermediate revision +1, and can_publish=false keys return pendingHumanApproval: true and stop at submit. It also references security/permission docs, giving the agent useful non-obvious context about how the publish flow can diverge.

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

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

The description is dense but efficiently structured: the core behavior is front-loaded, followed by required and optional parameters, then conditional behavior and doc references. Every sentence contributes actionable information without verbose filler.

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

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

For a publish workflow with four required parameters and one scheduling option, the description covers the full state flow, parameter provenance, conditional behavior, and security references. An output schema exists, so return-value documentation is not needed here. No important calling detail appears to be missing.

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

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

Schema coverage is 100%, so the schema already documents the parameters. The description adds meaningful cross-tool semantics by mapping revisionRowId to save_revision's id and revision to save_revision's revision, noting that the value immediately after save is acceptable. This contextualizes how to obtain the parameters, going beyond the raw schema.

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

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

The description states a specific action ('公開' / publish) and resource ('リビジョン'), and clarifies the one-call behavior 'draft→submit→approve', which distinguishes it from related workflow tools like submit_entry_for_review. It also enumerates the required identifiers, leaving no ambiguity about what the tool does.

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

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

The description provides clear context for when to use this tool: publishing a saved revision in a single call. It also gives a conditional exclusion for keys where can_publish=false, which stop at submit and require human approval in the Console. It does not explicitly name an alternative tool for manual submit, so it stops short of a full when-vs-alternatives statement.

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

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

Even though annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds substantial behavioral context beyond them. It discloses that dryRun:false/omitted is rejected without calling the API, that approved execution rewrites master_records.value and referenced Field snapshots, and that sort_order normalization may occur on other records. This is rich transparency that the annotations alone do not provide.

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

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

The description is dense but not bloated; every sentence conveys necessary constraints, warnings, or routing to propose_change. It is front-loaded with the purpose and required parameters, then covers behavior. Some redundancy exists with the schema-level description, but the tool's complexity justifies the length given the multiple parameter aliases and side-effect warnings.

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

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

The description covers the full workflow: what the tool does, required inputs, rejection behavior, execution path, side effects, and help references. With an output schema present, it does not need to describe return values. Minor gaps are the ambiguous 'schema/full' phrase and reliance on external help docs, but an agent has enough context to call this tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds value by clarifying the required combination groups (masterEntityKey + dryRun:true, slug or value, recordId or currentSlug/currentValue) and reinforcing that dryRun must be true. This cross-parameter logic is not obvious from individual property descriptions, so it earns above baseline.

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

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

The description clearly states the tool is a preview (schema/full) for renaming a Master Record's public identifier (slug/value). It explicitly says 'this tool does not write' and lists required parameters, making its scope unambiguous. It also differentiates from siblings by explaining that execution happens via propose_change and that update_master_record's value PATCH must not be used.

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

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

The description gives explicit when-to-use guidance: use this preview with dryRun:true, and then execute via propose_change(action: rename_master_record_slug). It explicitly warns against using update_master_record for this purpose and explains the consequences (snapshot breaks, 401). It also advises checking the dryRun preview for unintended sort_order changes, which is a clear conditional usage rule.

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