get_data_catalog

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the tool 'gets' information without describing whether this is a read-only operation, how results are returned (format, pagination), error conditions, or any rate limits. For a tool with 10 parameters and no annotation coverage, this is insufficient 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 appropriately brief with a single sentence purpose statement followed by parameter and return sections. However, the structure could be more front-loaded with critical usage information, and the Japanese/English mix may create clarity issues for some agents.

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 (10 parameters, no annotations) and the presence of an output schema, the description provides basic purpose and parameter semantics but lacks critical context about when to use it versus siblings, behavioral characteristics, and parameter interactions. The output schema reduces the need to describe return values, but significant gaps remain.

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?

With 0% schema description coverage, the description compensates by listing all 10 parameters with Japanese labels that provide semantic meaning (e.g., 'search_word: search keyword', 'stats_field: statistical field code'). This adds significant value beyond the bare schema, though it doesn't explain parameter interactions, format requirements, or default behaviors.

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 tool 'gets data catalog information' in Japanese, which translates to a clear verb ('get') and resource ('data catalog information'). However, it doesn't distinguish this tool from its many siblings (like get_data_catalog_csv, get_stats_list, search_stats_by_keyword), leaving the specific scope and differentiation unclear.

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 provided on when to use this tool versus alternatives. With 12 sibling tools including other catalog-related tools (get_data_catalog_csv) and search tools (search_stats_by_keyword), the description offers no context about appropriate use cases, prerequisites, or comparisons to similar tools.

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