housing_candidate_get

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds a concrete scoping constraint that goes slightly beyond that by spelling out the failure case for out-of-scope IDs. However, it says nothing about what happens on a missing/invalid ID (error vs empty result) or how much of the notice is returned.

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 short sentences, with the primary action front-loaded before the constraint. No filler, though the second sentence could be tightened into a single clause.

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 one-parameter read tool with full annotation coverage and no output schema, what is returned (notice details plus memo) and the storage scoping limit are stated. Minor remaining gaps are error semantics for unknown or malformed IDs.

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 schema only supplies a uuid format and v4 pattern for 'id' with no prose meaning. The description partially compensates by indicating the id must refer to a candidate saved in the current connection's storage. It still does not say whether the id is the candidate id from housing_candidate_save/list or a notice id.

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 gives a specific verb and resource: it retrieves the notice details and memo of a candidate the user has saved ('본인이 저장한 후보의 상세 공고·메모를 조회합니다'). This is clearly a read-one-by-id counterpart to housing_candidate_list/save, though it never names those siblings explicitly.

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 states a real precondition — only candidate IDs present in the current connection's storage can be retrieved ('현재 연결의 저장 공간에 없는 후보 ID는 조회할 수 없습니다') — which implicitly tells the agent to obtain the id from that storage first. It does not name an alternative tool (e.g., housing_candidate_list) or state when to prefer it over listing.

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