Skip to main content
Glama

brief

minimax_brief
Read-onlyIdempotent

Generates a read-only prioritized snapshot of sessions needing attention—waiting for your decision, errors, stuck, or running—to support status checks and triage.

Instructions

态势快照:按 等你决定>报错>卡住>运行中 优先级输出需关注的会话。纯读数据库,巡检首选。

Input Schema

NameRequiredDescriptionDefault
limitNo扫描会话数量
activeMinutesNo活跃会话判定阈值(分钟)
stalledMinutesNo未回复卡住判定阈值(分钟)
finishedMinutesNo刚完成判定阈值(分钟)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so "纯读数据库" largely restates structured data. What the description genuinely adds is the triage ordering of results by urgency, which is real behavioral disclosure. It reveals nothing about the returned shape (fields per session, ordering ties) or about how thresholds interact with the ranking.

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?

Two short clauses, purpose and priority ordering front-loaded, nothing padded. Minor waste in "纯读数据库", which duplicates the readOnlyHint annotation rather than adding new information.

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

Completeness3/5

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

For a read-only snapshot tool with no output schema, an agent still cannot tell what one entry in the snapshot looks like (session id, state, last activity, message excerpt) or how limit interacts with the priority ranking. Everything needed to call it is present; what to expect back is not.

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

Parameters3/5

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

Schema description coverage is 100%, so all four threshold parameters carry their own meaning and the baseline is 3. The description adds nothing about how activeMinutes, stalledMinutes, and finishedMinutes map onto the four priority buckets, which is the one place extra meaning would have helped.

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

Purpose4/5

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

The description names a specific output — a situation snapshot listing sessions that need attention — and states the exact priority ordering (等你决定 > 报错 > 卡住 > 运行中). That ordering distinguishes it from plain list or search siblings even though no sibling is named. It stops short of 5 because the resource being summarized (sessions) is only implicit in the word 会话.

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?

"巡检首选" gives a positive when-to-use signal: routine inspection / patrol. There is no explicit when-not guidance and no named alternative, so an agent must infer whether minimax_pending, minimax_list_sessions, or minimax_status is the better choice for a task other than a general sweep.

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