analyze_code_submission_programmers

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

No annotations are provided, so the description carries the full burden. It discloses that the tool generates an LLM analysis prompt by combining problem text and user code, lists the response structure (problemInfo, codeMetadata, analysisPrompts, suggestedQuestions), and warns about the platform ambiguity requiring user confirmation. This goes beyond a simple 'analyzes code' statement, though it does not detail edge cases like input validation or rate limits.

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 well-structured with clear sections for analysis types, response structure, supported languages, and a platform note. It is somewhat longer than necessary but each sentence contributes useful information, and the front-loaded purpose statement helps agents quickly understand the tool's role.

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 tool with 4 parameters, 3 required, and no output schema, the description is fairly complete. It provides the response structure, analysis type semantics, and platform resolution guidance. It does not provide an example invocation or specify the exact JSON shape of the generated prompt, but the given fields and the schema cover the essential needs for selecting and calling 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the meaning of each analysis_type (full, hint, debug, review) with one-line definitions, and lists supported languages that align with the language enum. It also clarifies that 'problem_id' can be a Programmers problem ID or URL. This enhances the schema descriptions, which merely name the fields.

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: '프로그래머스 문제에 대한 사용자 코드를 분석하여 피드백을 제공합니다' (analyzes user code for Programmers problems and provides feedback). It differentiates from siblings by specifying the Programmers platform and detailing distinct analysis types (full, hint, debug, review), which is unique to this tool.

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 implies usage for Programmers problems and includes an explicit platform identification guideline: if only a problem number is given, the agent must determine the platform from context or ask the user whether it is BOJ or Programmers. It does not explicitly say 'use BOJ tool for BOJ problems', but the sibling list and the platform note make the intended usage clear.

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