制造业管理工具箱 · Manufacturing Management Toolkit

manager_development

中基层管理者育成 · 梯队健康度诊断：按后备人才池与现任管理者数据，算后备覆盖率、代理试岗率、资格达成度、退出健康度与 GL 监督时间被侵占，输出梯队诊断报告 + HR 台账 CSV。

Args:
    positions: 关键管理岗位数（整数，如 "6"）。
    managers: 现任管理者 JSON 数组字符串（可留空）。每条形如
              {"id":"M01","name":"张GL","level":"GL","eval_result":82,"eval_prev":78,"supervision_ratio":0.62}。
    candidates: 后备人才 JSON 数组字符串（与 managers 至少给一个）。每条形如
              {"id":"C01","name":"李四","target_level":"GL","months_in_pool":9,
               "courses_done":["TWI-JI","TWI-JM","TBP/A3","安全管理","基础管理"],
               "kaizen_themes":3,"acting_months":4,"acting_score":81,"experience_years":7}。
    payment_proof: 支付宝支付凭证。首次调用留空 → 返回付款信息；付款后带入此参数重试。
    license_key: 买断/年费客户的授权码（有授权码则免付款）。与 payment_proof 填其一。

Input Schema

Name	Required	Description	Default
`managers`	No
`positions`	No
`candidates`	No
`license_key`	No
`payment_proof`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 8, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and delivers the most consequential behavior: this is a paid tool (payment_proof / license_key gate) with a documented two-step first-call-then-pay flow, plus the output format (diagnostic report + HR CSV ledger). It omits permission requirements and rate/limit behavior, but the billing/auth disclosure is substantial.

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

Conciseness4/5

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

Purpose and outputs are front-loaded in the first sentence, followed by per-parameter Args. The embedded JSON examples are verbose but justified given 0% schema coverage. No filler sentences, though the block is longer than an ideal description.

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

Completeness4/5

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

An output schema exists, so return values need not be spelled out, and the description correctly focuses on inputs and the payment gate. The one gap is operational routing (when to use vs siblings), but for a 5-param diagnostic tool with rich param docs this is largely complete.

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

Parameters5/5

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, and it does: every one of the 5 parameters is explained, including full JSON shapes and field meanings for managers and candidates, integer typing for positions, and the mutual-exclusion rule between payment_proof and license_key. This is exactly what the bare schema lacks.

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?

States a specific verb (算/诊断) and resource (中基层管理者育成 · 梯队健康度), and enumerates the exact metrics computed (后备覆盖率, 代理试岗率, 资格达成度, 退出健康度, GL 监督时间) plus both output artifacts. An agent can tell this apart from the other HR/ops siblings without opening the schema.

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

Usage Guidelines3/5

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

It does give a concrete invocation flow: first call with empty payment_proof returns payment info, then retry with proof, or supply a license_key instead. However, it says nothing about when to choose this tool over alternatives (e.g. tbp_problem_solving or vital_organization) or any prerequisites/exclusions.

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

All 制造业管理工具箱 · Manufacturing Management Toolkit tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?