fm_list_value_lists

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('取得します' - retrieves), which implies it's non-destructive, but doesn't address other behavioral aspects such as authentication requirements, rate limits, error handling, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond the basic read intent.

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 in two sentences: the first states the core action and resource, and the second adds practical context (checking dropdown options). There is no wasted text, and it's front-loaded with the main purpose. However, it could be slightly more efficient by combining ideas, but it remains clear and to the point.

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 no annotations, no output schema, and 1 parameter with full schema coverage, the description is incomplete. It adequately explains what the tool does but lacks critical behavioral details (e.g., authentication needs, response structure) and usage guidelines. For a tool in a context with sibling tools and potential complexity (e.g., related to layouts and value lists), more comprehensive information is needed to ensure the agent can use it effectively.

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 100% description coverage, with the single parameter 'layout' documented as 'レイアウト名' (layout name). The description adds minimal context by mentioning '指定されたレイアウトで' (in the specified layout), reinforcing the parameter's role but not providing additional semantics like format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding 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 tool's purpose: '取得します' (retrieves/gets) '値一覧(Value Lists)' (value lists) '指定されたレイアウトで利用可能な' (available in the specified layout). It specifies the verb (retrieve) and resource (value lists) with context (layout-specific). However, it doesn't explicitly distinguish this from sibling tools like fm_get_layout_metadata or fm_get_layouts, which might also retrieve layout-related information.

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 minimal guidance: it implies usage when you need to check dropdown options in fields for a layout. However, it doesn't specify when to use this tool versus alternatives (e.g., fm_get_layout_metadata might provide similar or overlapping data), nor does it mention prerequisites (e.g., authentication, session validity) or exclusions. No explicit when/when-not or alternative tool references are provided.

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