Skip to main content
Glama

power_curve

Read-only

Compute a complete level-to-power curve from a growth table: sample rows, auto-detect attribute columns, and return start/mid/end power, growth multiplier, and curve shape classification.

Instructions

战力曲线(批量):读成长表逐行(可采样)属性面板调 computePowerStats,一次产出「等级→战力」全曲线与形态摘要(首/中位/末档战力、成长倍率、形态判定:匀速/后期加速/台阶断点)。属性列自动按常用名识别(攻击/攻击力→attack、体力/生命→hp、防御→defense、攻速/速度→speed、暴击率→crit),识别不到时用 columns 显式指定。适合全曲线分析与成长×装备联合推导,替代多次单点 compute_power。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tableYes成长表名(如 hero/成长表)
columnsNo显式列映射 {attack:'属性.攻击', hp:'属性.体力', defense?, speed?, crit?}——自动识别失败或需换列时用
levelColumnNo等级/序号列名,缺省取首列
sampleEveryNo采样间隔(默认自动:行数>60 时取 ceil(行数/60)),首末行恒在采样内

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses sampling behavior, automatic column-name recognition with fallback to explicit columns, and the concrete output composition including first/median/last power, growth multiplier, and shape classification. This is substantial behavioral context that the annotation alone does not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every clause earns its place: input, sampling, output, auto-mapping, fallback behavior, and intended use case. It is front-loaded with the core batch-curve purpose and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still enumerates the output fields and shape classifications. The schema covers all parameters and the annotation marks the tool read-only, so nothing essential is missing for correct invocation and interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real parameter semantics: concrete auto-name mappings (攻击力→attack, 体力→hp, etc.), explicit column-mapping examples, and the guarantee that first/last rows are always included when sampling. This raises it above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific action plus resource: it reads a growth table and produces a level-to-power curve with shape summary metrics. It explicitly distinguishes itself from compute_power by presenting itself as the batch/full-curve version and stating it replaces repeated single-point calls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states when to use the tool: full-curve analysis and growth × equipment joint derivation, and it names compute_power as the single-point alternative it replaces. It does not explicitly state a when-not-to-use condition, but the context is clear enough for an agent to choose correctly.

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