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

With no annotations, the description must carry the burden of disclosing behavior. It notes the cli mode requires local Python and advanced_pyexamine installation, but does not state whether the analysis is read-only, may modify files, or has other side effects. This is insufficient for an analysis 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 sentences, no fluff. The main function is front-loaded, and the cli prerequisite is an important behavioral note. It's appropriately compact.

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 and no output schema, the description gives a high-level overview and a prerequisite, but lacks details about result structure or workflow integration. It's adequate for basic use but not fully complete given the sibling complexity.

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 covers 100% of parameters with descriptions, and the description adds no parameter-specific semantics beyond the schema. Baseline of 3 applies.

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 it analyzes a Python project using advanced_pyexamine and returns smell results as JSON. The verb 'analyze' distinguishes it from sibling 'get' tools that retrieve existing results, though it doesn't explicitly name alternatives.

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 explicit guidance on when to use this tool versus siblings like get_latest_pyexamine_result or get_smells_by_file. The description implies it's for running a new analysis but lacks clear context and exclusions.

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

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

With no annotations, the description states the ordering behavior ('최신순' = latest first) but does not explicitly disclose read-only nature, filtering behavior, or pagination. The term '조회' implies a read operation.

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?

A single sentence that is informative and free of redundant details.

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?

The description is adequate for a simple list tool with fully documented parameters, but lacks explicit return-value information and alternatives, making it slightly under-specified for an agent without prior context.

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?

All four parameters have descriptions in the schema, so the description adds no additional parameter meaning beyond naming the resource and ordering.

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 uses the verb '조회한다' (retrieves) with a specific resource ('code-analysis 결과 목록' from CodeVi backend), clearly distinguishing it from sibling tools that deal with metrics or smells.

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 explicit guidance is given about when to use this tool over alternatives like list_metric_analyses or list_smell_analyses, but the focus on code-analysis results implies its use for listing such results.

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

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

With no annotations, the description carries the full burden. It discloses one behavioral trait: if commitHash is absent, the latest result is used. This is valuable but does not cover other aspects such as read-only nature, authentication requirements, or output format.

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 extremely concise: two sentences that directly state the purpose and the key behavioral note. No wasted words, and the main action is front-loaded.

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 presence of multiple sibling tools (e.g., get_smells_by_file, get_pyexamine_result_by_commit), the description does not clarify when to use this tool versus those. The lack of an output schema and annotations further increases the burden, but the description only covers the basic retrieval behavior and one fallback rule.

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 schema already provides descriptions for all parameters (100% coverage). The description adds meaning by explaining the commitHash fallback behavior, which goes beyond the schema's simple 'commit hash 필터'. This enhancement justifies a score above the baseline of 3.

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 retrieves a list of high severity smells, using the verb '조회한다' (retrieve) and the resource 'high severity smell 목록' (high severity smell list). The mention of commitHash fallback adds specificity. However, it does not explicitly differentiate from siblings like get_smells_by_file or get_code_analysis_results.

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 retrieving high severity smells, and the note about commitHash absence using the latest result gives some contextual guidance. However, there is no explicit mention of when to prefer this tool over alternatives, nor any exclusions.

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

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

With no annotations provided, the description carries full burden, but it only states 'most recent' without explaining return format, behavior when no result exists, or whether filters combine additively. It also does not clarify what pyExamineResult is or any read-only property.

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 a single, concise Korean sentence that directly communicates the tool's purpose with no unnecessary words. It is front-loaded and minimally sized.

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 simple read tool with no output schema and no annotations, the description is adequate but sparse. It does not explain return shape or how to differentiate from get_pyexamine_result_by_commit, leaving some gaps for the agent to infer behavior.

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?

All three parameters (jobName, commitHash, teamProjectId) are fully described in the schema, so the description adds no extra semantics beyond the existence of filters. Baseline 3 applies because schema coverage is 100% and the description does not add further usage detail.

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 retrieves the most recent code-analysis result containing pyExamineResult, using a specific verb (조회한다) and resource. This distinguishes it from siblings like get_pyexamine_result_by_commit, which filters by commit, and from list-type tools.

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 when to use it (when needing the latest pyExamineResult), but provides no explicit guidance on when to prefer it over similar siblings like get_code_analysis_results or get_pyexamine_result_by_commit, nor any exclusion criteria.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It states the operation is a retrieval (조회), indicating a read action, but does not add context about error cases, return format, or permissions. It is minimally transparent but not misleading.

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 a single, succinct sentence in Korean. It includes meaningful qualifiers (저장된, 단건) that clarify the scope without unnecessary words, making it concise and well-structured.

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?

This is a simple get-by-ID tool with one parameter and no output schema. The description confirms it retrieves a single analysis, but it does not clarify whether the response contains the full analysis object or just a summary, which is relevant given sibling tools like list_metric_analyses. Minimal but adequate for a basic lookup.

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%: the jobId parameter is described as "조회할 metric analysis job ID" (metric analysis job ID to retrieve). The description adds no additional meaning about the parameter beyond the schema, so the baseline score of 3 is appropriate.

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 retrieves a single saved metric analysis ("저장된 metric analysis 단건을 조회한다"), using a specific verb (retrieve) and resource (metric analysis) with a singular scope (단건). This distinguishes it from the sibling tool list_metric_analyses, which retrieves multiple analyses.

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 when to use the tool: when you need a specific metric analysis by job ID. It provides clear context for a single-record lookup but does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

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

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

Annotations are absent, so the description carries the full burden. It only says 'query results based on commit hash' and provides no detail on return format, error handling (e.g., missing commit), or whether teamProjectId is required in certain situations. The description does not disclose any behavioral traits beyond the basic read operation.

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 a single, concise sentence that front-loads the key criterion (commit hash) and clearly states the action and resource. There is no redundant information or unnecessary detail.

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?

The tool is a simple lookup with 2 parameters, both documented in the schema. There is no output schema, so return value disclosure is not required. However, the description lacks any guidance on how this tool relates to siblings like get_latest_pyexamine_result or get_code_analysis_results, which is a meaningful gap for correct tool selection.

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 100%, meaning both commitHash and teamProjectId have descriptions in the schema. The tool description adds nothing beyond what the schema already provides, so the baseline score of 3 is appropriate.

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?

Description clearly states 'commit hash 기준으로' (based on commit hash) and 'code-analysis(PyExamine) 결과를 조회한다' (query PyExamine results), indicating a specific retrieval action with a specific resource. This differentiates it from siblings like get_latest_pyexamine_result or get_code_analysis_results by explicitly scoping to commit hash.

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. It does not mention that it is intended for querying results by a specific commit, nor does it contrast with get_latest_pyexamine_result for latest results or get_code_analysis_results for general queries. This leaves the agent to infer the usage context.

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

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

With no annotations, the description carries the full burden. It implies a read-only operation via the verb 'retrieve', but it does not disclose behaviors such as not-found handling, permission requirements, rate limits, or absence of side effects. The 'findings array' note is a small behavioral hint, but it is insufficient for full transparency.

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 two short sentences, front-loading the primary action and adding only the key output detail ('findings 배열 포함'). There is zero redundant wording, and every word earns its place. This is a model of conciseness.

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 single-parameter read tool with no output schema, the description is mostly complete. It states the resource and the key output field, and the schema covers the input. It lacks error-handling context or relationship to sibling tools, but given the simplicity, the essential information for invoking the tool correctly is present.

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 schema fully documents the only parameter jobId with a description ('조회할 smell analysis job ID') and a minimum constraint. The description adds no additional parameter semantics, such as how to obtain a job ID or any format details. With 100% schema coverage, the baseline of 3 is appropriate; the description does not need to compensate.

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 action ('retrieves' via '조회한다') and the resource ('saved single smell analysis detail'). It also notes the 'findings array' inclusion, which distinguishes it from list-style siblings by emphasizing a single-item lookup. However, it does not explicitly differentiate from other sibling get tools like get_code_analysis_results, so it does not fully maximize sibling distinction.

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. The description does not mention that jobId would come from a list or save operation, nor does it recommend using list_smell_analyses to find job IDs. This leaves the agent without explicit selection criteria.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds the commitHash fallback behavior, which is useful, but does not mention return format, error scenarios, or performance considerations. The word '조회' implies read-only, but safety is not explicitly stated.

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 two short sentences, front-loaded with the main purpose and a key conditional. No fluff; every word earns its place.

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 5-parameter tool with no annotations and no output schema, the description covers the core purpose and one behavioral nuance but leaves out details like partial matching of filePath and response structure. It is adequate but has clear gaps in completeness.

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 covers all 5 parameters, and the description adds meaning beyond the schema by explaining the default behavior of commitHash and highlighting filePath as the primary filter. This adds value for those two parameters, though others are left to 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 retrieves a smell list based on file path, providing a specific verb, resource, and scope. It distinguishes from siblings like list_smell_findings or get_smell_analysis by emphasizing the file path criterion.

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 context: use when filtering by file path, and notes that without commitHash the latest result is used. This provides clear context, though it does not explicitly mention alternatives or exclusions relative to sibling tools.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool retrieves a list, with no mention of filtering behavior, return format, whether it is read-only, or any limitations. This is a minimal disclosure that leaves the agent without expectations for the operation's behavior.

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 a single, concise sentence that states the resource and action without unnecessary detail. It is front-loaded and easy to parse.

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?

The tool has no output schema and no annotations, so the description should explain what the response contains or how to use the filters. It only provides the basic purpose, omitting information about return structure, pagination, or how optional parameters affect results. This is incomplete for an agent to use 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 description makes no mention of the parameters, but the input schema covers two of three parameters with descriptions and the status parameter has a self-explanatory enum. Schema description coverage is moderate (67%), so the description adds no extra meaning, but the schema provides adequate context for parameter usage.

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 a specific action ('retrieves the list') and a clear resource ('metric analysis history stored in CodeVi backend'). This clearly distinguishes it from sibling tools like get_metric_analysis (singular) and list_smell_analyses (different analysis type).

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 as a list operation but does not explicitly state when to use this tool versus alternatives such as get_metric_analysis or run_metric_analysis. No exclusions or conditional guidance are provided, leaving the agent to infer from the tool name and context.

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

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

With no annotations provided, the description must disclose behavioral traits, but it only states the basic listing operation. It does not mention pagination defaults, filtering behavior, ordering, or any side effects. The description adds no behavioral context beyond what the tool name already implies.

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 a single short sentence with no wasted words, but it is severely under-specified. It lacks essential information about the tool's behavior and parameters, making it incomplete rather than concisely effective.

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?

This tool has 8 parameters, no output schema, and no annotations, yet the description provides no context about return format, filtering, pagination, or typical usage. It is entirely inadequate for an agent to select and invoke the tool correctly, especially given the many sibling tools with overlapping purposes.

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 low (38%), and the description does not explain any of the 8 parameters. It fails to mention that teamProjectId is required, or that limit, offset, status, analyzer, etc., are filters. The description adds no semantic value beyond the schema's minimal field descriptions.

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 a specific verb ('조회한다' = retrieve) and resource ('smell analysis 목록' = list of smell analyses), making its primary function clear. However, it does not distinguish itself from sibling tools like 'get_smell_analysis' (singular) or 'list_smell_findings', so it lacks explicit differentiation.

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. The description only says 'retrieves the list', with no mention of typical use cases, required context (e.g., teamProjectId), or when to prefer this over other list/detail tools.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only mentions filtering criteria but doesn't explain pagination (limit/offset), ordering, empty results, or error behavior. The dashboard note is usage context, not actual tool behavior.

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 two short sentences with the core purpose front-loaded and no redundant text. It is appropriately concise and well-structured.

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 7-parameter tool with no annotations and no output schema, the description is too sparse. It doesn't describe the return value structure, pagination behavior, or constraints on jobId. The dashboard context doesn't satisfy the need for more complete tool documentation.

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 description names severity, name, and filePath as filter dimensions, which adds meaning to those schema parameters. However, it doesn't mention the required jobId explicitly or address pagination parameters (limit, offset), and schema coverage is only 57%, so it only partially compensates for the gaps.

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 it retrieves a finding list for a specific job with filtering by severity, name, filePath, etc., and mentions the dashboard detail table use case. This distinguishes it from sibling tools like list_smell_analyses (which lists analyses) and get_smells_by_file (which is file-specific).

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 provides clear usage context by explicitly stating it's used for displaying a dashboard detail table. However, it doesn't mention when not to use it or name alternative tools like get_high_severity_smells or get_smells_by_file, so it stops short of explicit exclusion guidance.

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

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

With no annotations, the description carries the full burden of disclosing behavioral traits. It mentions that results are stored, implying a side effect, but it does not explain permissions, execution duration, failure handling, or whether the operation is asynchronous. Minimal side-effect disclosure is present but insufficient for a run/execute 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?

The description is a single sentence, direct and free of redundant details. It communicates the core action and resource clearly. While it is terse for a tool with 7 parameters, the sentence earns its place by stating purpose concisely.

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 (7 parameters, nested objects, no output schema) and the absence of annotations, the description is not complete enough. It omits information about return values, side effects, and when to use this tool relative to other analysis tools. The description leaves significant gaps for an agent to safely invoke the tool.

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?

All 7 parameters have schema descriptions (100% coverage), so the baseline is 3. The description itself adds no parameter semantics beyond what the schema provides, and it does not clarify interdependencies like how sourceType determines whether astData or sourceCode is relevant. The schema does the heavy lifting.

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: requesting the CodeVi backend to execute metric analysis and store the results. This distinguishes it from sibling get/list tools and other analysis tools. The verb 'run' is implicit in the tool name, and the resource is explicitly 'metric analysis'.

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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or how it relates to sibling tools like get_metric_analysis or analyze_python_smells. There is no 'use this when' context.

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

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

With no annotations, the description does disclose meaningful behavior: the backend workflow via /analyze, persistence of findings, and the constraint that projectPath must be a container-side path. However, it omits side-effect details such as whether results are overwritten, idempotency, authentication, or response/return behavior.

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 three tightly written sentences: purpose, backend mechanism, and a key parameter warning. Every sentence contributes useful information with no filler.

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 10-parameter tool with no output schema and no annotations, the description gives a useful high-level flow but leaves out what the tool returns after saving, how to link results to subsequent getters, and any prerequisites. It is adequate but has clear gaps.

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 90%, so the schema already documents most parameters. The description only reinforces the projectPath container-path guidance, which duplicates the schema's own parameter description, adding no new semantic value beyond it.

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 a specific action: request smell analysis execution from the CodeVi backend and save results. It also adds distinctive detail by mentioning the backend calls advanced-pyexamine-service /analyze and stores findings, which separates it from pure getter or metric-analysis tools.

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 given on when to use this tool versus siblings like analyze_python_smells or run_metric_analysis. The description only mentions a projectPath requirement, not decision criteria or exclusions.

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