Update excluded regions and shipping services across multiple eBay policies using a partial name filter. Add or remove exclusions, with a dry-run preview to confirm changes before applying.
ポリシー名フィルタで一括除外設定更新（部分一致）
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | trueでプレビューのみ、falseで実際に反映 | |
| filter | No | ポリシー名の部分一致フィルタ（空なら全ポリシー対象） | |
| addExclusions | No | 追加する除外項目の表示名配列 | |
| removeExclusions | No | 解除する除外項目の表示名配列 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose risk and side effects, but it only restates that an update occurs. It says nothing about dryRun defaulting to true, the actual write when dryRun=false, whether matching exclusions are replaced or merged, or irreversibility—serious omissions for a mutation tool.
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 short phrase conveys action, resource, bulk scope, and the matching mechanism, with the key 'bulk + filter' information front-loaded. No filler or redundancy; 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?
Although the schema richly explains all parameters, the description itself offers only purpose, with no guidance on safe execution (dryRun preview), side effects, or fallback to update_exclusions, and there is no annotation or output schema to fill those gaps. An agent can identify the tool but not confidently reason about what applying the updates will do.
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 applies: the schema fully documents dryRun, filter, addExclusions, and removeExclusions. The description adds only the filter's partial-match aspect, which duplicates schema content and does not compensate for anything.
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 combines a specific verb (更新/update), resource (除外設定/exclusion settings), and scope (一括/bulk via policy-name filter), clearly distinguishing it from the singular update_exclusions and read-only get_policy_exclusions siblings. Even without a title, the action and filter mechanism are unmistakable.
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 'bulk' + 'policy name filter' phrasing implies this is for updating many policies at once, and the sibling name update_exclusions signals the singular alternative. However, no explicit when-to-use, when-not-to-use, or alternative routing is provided; the usage guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.