Calculate peer cohort expected ranges (P10/P50/P90) for company metrics and show each metric's position. Returns benchmarks and key drivers from quantile models or cohort tables.
지표별 동종 코호트 기대범위(P10·P50·P90)와 위치를 계산합니다. 학습된 CatBoost 모델이 있으면 분위수 회귀와 SHAP 요인을, 없으면 카탈로그 코호트 표를 씁니다(샘플 표 사용 여부를 함께 반환). metrics: compute_metrics 결과의 metrics 목록. company_features: 산업·매출·인원·업력 등.
| Name | Required | Description | Default |
|---|---|---|---|
| cohort | No | ||
| metrics | Yes | ||
| company_features | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a fair job: it discloses the internal branching (CatBoost quantile regression + SHAP factors when a trained model exists, otherwise the catalog cohort table) and that a sample-table flag is returned. It does not cover permissions, cost, or error behavior, but the computational behavior is genuinely explained.
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?
Purpose is front-loaded in the first sentence, with fallback behavior and parameter notes following. The parenthetical about the sample-table return flag is slightly extraneous but overall the text is tight 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?
There is no output schema and no annotations, so the description must do the work; it helpfully names the returned percentiles, position, SHAP factors, and sample-table flag. However, the undocumented cohort parameter and the absence of any when-to-use framing leave meaningful gaps for a 3-parameter 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?
Schema description coverage is 0%, so the description must compensate. It adds real meaning for two parameters — metrics (output of compute_metrics) and company_features (industry, revenue, headcount, tenure) — but the cohort parameter is never mentioned, leaving one of three parameters undocumented.
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 verb (계산합니다 / computes) and resource (peer-cohort expected range P10·P50·P90 and each metric's position), and it ties its input to the sibling compute_metrics. It is clear what the tool produces, though it never explicitly frames itself against the other siblings (assess_stage, screen_patterns), so differentiation is implied rather than stated.
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?
Usage context is only implied: the metrics parameter is described as coming from compute_metrics results, which hints at the required upstream step, but there is no explicit 'use this when / not when' or comparison to alternatives. The model-vs-catalog branching is internal behavior, not user-facing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.