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

Richly discloses behavior beyond annotations: the CSV body is intentionally not returned, a preview with row count/column names/first 20 rows is returned, the file is saved to a temp directory unless save_path is set, existing files are not overwritten, and insufficient permissions cause a 403. This gives the agent a clear mental model of side effects and failure modes.

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 front-loaded with the core purpose, then organized into lookup guidance, permissions, output behavior, and error handling. Every sentence carries actionable information; nothing is redundant or filler despite the length.

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 an 8-parameter tool with no output schema and minimal annotations, the description covers the essentials: what is returned, how files are saved, permission requirements, ID sourcing, and error recovery. An agent can invoke this tool and interpret its result correctly without external context.

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 value by telling the agent where to source group_cd and device_cd (list_groups/list_devices), which the schema does not, and by explaining save_path overwrite behavior. The 'all' special value and absolute-path rule are already in the schema, so the added value is meaningful but not extensive.

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 first sentence states a specific verb and resource: export received data history as CSV. It also clarifies the actual deliverable (a saved UTF-8 file and absolute path, not the CSV body), which immediately distinguishes it from the sibling list_* 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 strong usage context: tells the agent to obtain tenant_id/group_cd/device_cd from specific list_* tools, explains the 'all' option for full datasets, and gives recovery guidance when the API limit returns 400. It does not explicitly frame when not to use this tool, but no sibling is a true alternative for export, so this is a minor gap.

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 (readOnlyHint=true, destructiveHint=false), the description discloses important behaviors: required permission levels, 403 on insufficient rights, no paging, always returning all items, and that envelope page/per_page will be null. This is substantive behavioral information that 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 organized with a leading purpose sentence, followed by prerequisite, authorization, and pagination behavior. Each sentence adds distinct, necessary information and there is 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?

For a single-parameter read-only listing tool, the description covers how to obtain the required parameter, required permissions, the error case, and pagination semantics. This is sufficient for an agent to invoke the tool correctly without an output 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?

The input schema already describes tenant_id as a UUID obtainable via list_tenants, and the description largely repeats this. With 100% schema description coverage, the baseline of 3 applies; the description adds permission context but not new parameter semantic details.

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: '地点用ダッシュボードの一覧を取得します' (retrieves the list of site/location dashboards). The resource is clear from the name and description, but it does not explicitly contrast with sibling tools such as list_tenant_dashboards or list_group_dashboards, so sibling differentiation rests mostly on 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?

The description provides clear usage context: tenant_id should be obtained via list_tenants, required permission levels are described, and the 403 failure case is specified. It does not explicitly mention when to prefer this tool over alternatives, 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?

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description adds critical behavioral detail: default thinning of format_detail and address fields, the specific effect of include flags, and the quirk that periodic_collection may be null for legacy devices and is returned as null rather than conflated with 'stop'. This is exactly the kind of non-obvious runtime behavior an agent needs to interpret results correctly.

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 moderately long but every sentence earns its place: purpose, permission, thinning defaults, flags, and a null-handling caveat are all packed into a clear structure with dash-prefixed bullets. The most important purpose statement is front-loaded, and there is no redundant or filler 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?

Given the tool has 6 parameters, no output schema, and annotations that already cover safety, the description covers the essential behavior: data source equivalence, prerequisites, permission, filtering, thinned fields, and null semantics. Minor gaps include lack of explicit mention of pagination behavior or response structure, but the 'same info as web admin edit list' reference partially compensates for the missing output 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 parameters are already documented. The description adds meaningful semantics by explaining the practical consequences of include_format_detail (hundreds of items per format) and include_alerts (includes email addresses), and by clarifying that group_cds supports OR filtering. It does not discuss page/page_size, but those are straightforward and already covered by 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 a specific verb and resource: 'テナントに紐づく地点（端末）の一覧を取得します' (retrieves the list of locations/devices linked to a tenant). It also distinguishes itself by stating it returns the same information as the web admin location edit list, and it references sibling tools list_tenants and list_groups for prerequisite IDs, clearly separating it from list_users, list_formats, and dashboard 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 explicitly tells the agent to obtain tenant_id via list_tenants, and explains when to enable include_format_detail and include_alerts based on data volume needs. It also states permission requirements ('制限なし'), providing clear invocation context. It does not explicitly say 'do not use for dashboards' or name list_device_dashboards as an alternative, though the sibling names make that implicit.

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 readOnly/destructive annotations, the description discloses permission requirements, 403 behavior, that item definitions are excluded, that koumoku_count provides item counts, and that no thinning/sampling is performed. This gives the agent a rich behavioral model of the 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?

The description is concise but information-dense. Every sentence adds a distinct fact: purpose, tenant_id source, permissions, response boundaries, and alternative tool routing. The most important facts are front-loaded.

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?

There is no output schema, so the description partially carries the burden of explaining the response. It clarifies what is not returned and mentions koumoku_count, but it does not enumerate the actual response fields. Still, this is nearly complete 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?

The schema already documents all parameters with 100% coverage, so the baseline is 3. The description adds value by explaining where to get tenant_id and by clarifying that 403 errors are about API user permissions rather than parameter correctness.

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 starts with a specific verb and resource: retrieving the list of tenant formats/models. It also explicitly distinguishes itself from list_devices by stating that item definitions are not included, making the purpose clear relative to 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?

It gives explicit guidance: obtain tenant_id from list_tenants, requires system administrator level, and 403 should be interpreted as a permission problem rather than a parameter problem. It also names the exact alternative, list_devices with include_format_detail=true, when item definitions are needed.

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?

With no annotations present, the description carries the full burden and adds valuable behavioral detail: no paging support, always returns all records, page/per_page will be null, and insufficient permissions yield 403. It does not literally say 'read-only' but '取得' strongly implies a safe GET-like operation.

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?

Purpose is front-loaded and every sentence addresses a distinct concern: tenant acquisition, permissions, and paging. There is minor redundancy with the schema's tenant_id description, but overall the structure is efficient and scannable.

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, the description covers prerequisites, permission failure, and pagination behavior. There is no output schema, and the description does not describe response fields; however, enough information is present to 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?

The only parameter, tenant_id, is already well described in the input schema with type UUID and source via list_tenants. The description repeats this guidance without adding meaningful new semantics, so the baseline score 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?

Description opens with '現場用ダッシュボードの一覧を取得します', naming a specific verb and resource. It clearly identifies a read/list operation and is distinguishable from sibling tools like list_formats and export_observation_data.

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?

Explicitly instructs that tenant_id should be obtained via list_tenants and states the required permission levels with 403 behavior. It gives clear context for valid invocation, though it does not explicitly say when not to use this tool versus an alternative.

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 is rich in behavioral caveats: default thinning of email-containing fields, children always empty, dashboard_id omitted, and max_group_level returned. However, it directly contradicts the openWorldHint annotation by claiming the endpoint 'always returns all records' (常に全件を返します), while openWorldHint signals that the result set may not be complete.

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 organized with purposeful sections: purpose, precondition, permission, default field thinning, and pagination. Every sentence adds operational value and the structured bullets make the behavior 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?

For a read-only list tool with no output schema, the description covers the key output transformations, permission requirements, paging behavior, and hierarchy limitations, so an agent can understand what it will receive. It loses some completeness because the exhaustiveness claim conflicts with openWorldHint, but the rest of the call context is well covered.

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 complete, and the description adds meaningful parameter context: include_members and include_destinations control whether full email-containing fields are returned, and tenant_id is sourced from list_tenants. This goes beyond the schema's basic field 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 clearly identifies the verb ('一覧を取得') and resource ('テナントに紐づく現場/グループ'), so the agent knows exactly what the tool returns. It is distinct from sibling list tools by specifying 'グループ' as the domain object and referring to list_tenants for 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 gives practical usage context: tenant_id comes from list_tenants, no special permission is required, and the endpoint has no pagination. It does not explicitly contrast this tool with siblings such as list_group_dashboards, but the stated context is clear enough for correct 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 indicate readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: required permission levels, the 403 error for insufficient permissions, and the fact that pagination is unsupported so all records are always returned with page/per_page null.

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 purpose. Each subsequent sentence adds distinct value: parameter sourcing, permissions, error behavior, and pagination behavior. There is no redundant or filler 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 single-parameter read-only list endpoint, the description covers the essential operational facts: purpose, parameter source, permission requirements, error case, and pagination behavior. It does not describe the shape or fields of returned dashboards, but this is not critical for correctly invoking the tool and no output schema exists to supplement 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 description coverage is 100% and the schema already documents tenant_id as a UUID obtainable from list_tenants. The description repeats this guidance without adding additional parameter semantics, so the baseline of 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 the specific verb '取得します' (retrieve) and the exact resource 'テナント用ダッシュボードの一覧' (list of tenant dashboards). The resource scope clearly distinguishes it from sibling tools like list_device_dashboards and list_group_dashboards.

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 context by explaining that tenant_id should be obtained from list_tenants and specifying required permission levels. It does not explicitly compare with sibling tools or state when not to use this tool, so it misses a full 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, so the description does not need to restate safety. It adds valuable behavioral detail beyond annotations: no permission restrictions, tenant_logo is omitted by default and replaced with has_logo(bool), and image retrieval is impossible. This meaningfully informs an agent about response size and data constraints.

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 well-structured. It leads with the core purpose, then gives workflow guidance, permission level, and important response-thinning behavior. Every sentence contributes useful information without 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?

For a low-complexity tool with no required parameters and no output schema, the description covers the essential operational details: purpose, first-use workflow, permission level, and a notable response-field omission. It could be slightly more complete by explicitly listing the returned fields, but the mention of tenant_id and has_logo gives enough guidance 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%, so the parameters page and per_page are already fully documented. The description adds no additional parameter-level semantics beyond what the schema provides, which matches the baseline score of 3.

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 with a specific verb and resource: 'テナント一覧を取得します' (retrieves the list of tenants). It also differentiates the tool from siblings by positioning it as the necessary first step for obtaining tenant_id, which most other tools require, making its role distinct.

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 usage context: 'SaaS_A の調査はまずこのツールで tenant_id を取得することから始めてください' explicitly tells the agent when to use this tool. It does not explicitly name alternatives or when-not-to-use conditions, but the workflow guidance is strong enough for 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?

Beyond the readOnlyHint/destructiveHint annotations, the description reveals that the response contains the personal mailaddress, warns against unnecessary transcription, states that no permission level is required, and confirms no thinning/truncation is performed. This is substantive 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 compact and front-loaded: purpose first, then prerequisite, permission, response privacy, and behavioral note. Each sentence contributes distinct 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 simple paginated list endpoint, the description covers purpose, prerequisites, permissions, and a key response field. Without an output schema, it does not enumerate all user fields beyond mailaddress, which leaves a small gap in expected response shape.

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 tenant_id, page, and per_page fully. The description only repeats that tenant_id comes from list_tenants, which the schema already says, so it adds no meaningful parameter semantics.

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 clear action and object: 'テナントに所属するユーザーの一覧を取得します' (get the list of users belonging to a tenant). This distinguishes it from sibling list_tenants/list_groups/list_devices by resource, though it does not explicitly contrast itself with them.

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 gives actionable context: tenant_id should be obtained from list_tenants first, and it states there is no permission restriction. It does not explicitly say when not to use this tool or name an alternative for a different resource, but the prerequisite workflow is clear.

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