list_companies

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

With no annotations supplied, the description carries the full burden, and it does disclose one real behavioral fact: the result is scoped to '수집 대상' companies (collection targets), not an arbitrary company directory. It says nothing about ordering, result volume, exhaustiveness, pagination, or what happens with an unknown category, so it is only minimally viable for an unannotated 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?

Two compact clauses, front-loaded with the resource and followed immediately by the filtering option and its values. No filler, no restatement of the tool name, nothing that could be cut.

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?

Complexity is low (one optional parameter, read operation) and an output schema exists, so return-value documentation is not required. However, an agent still cannot tell whether the list is exhaustive or paginated, or how large it typically is, which matters for a listing tool with no annotations to fall back on.

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 0%, so the description must compensate, and it does: it names the 'category' parameter and enumerates six concrete values (대기업, 대기업 계열사, 중견기업, 강소·유망, 공기업, 외국계) that appear nowhere in the schema. It stops short of confirming the values are exhaustive, exact-match strings, or that omitting category returns all companies.

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 names the resource precisely ('수집 대상 기업 리스트' – the list of companies in the collection pool) and its filtering axis, which is enough to separate it from the job-oriented siblings (fetch_jobs, search_jobs, get_job_detail). It never uses an explicit verb such as 'returns/lists', relying on the noun '리스트', which keeps it just short of 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?

It hints at usage by saying results 'can be filtered by category', but gives no when-to-use condition, no prerequisites, and no reference to any sibling tool or when a company lookup is preferable to a job lookup. An agent must infer the calling context entirely.

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