mattermost_auth_status

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: it operates on an already-stored token (hence zero arguments) and it deliberately does not return the token itself. It does not say what 'validating' yields (a boolean, user identity, an error on expiry) or whether it refreshes the session, which are the details an agent most needs.

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 short sentence, front-loaded with the action and scoped by a clarifying clause. Nothing is wasted, though the extreme brevity means little structure beyond one clause.

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 zero-parameter, output-schema-less tool, the description is minimally adequate: it establishes inputs (none, stored token) and one output constraint (no token returned). The actual return shape on success and failure remains undefined, which is a real gap given no output schema exists.

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 tool takes zero parameters, so the baseline is 4. The description correctly signals that no credentials need to be passed because the token is stored.

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 pairs a specific verb (驗證/validate) with a specific resource (the saved Mattermost session token), and '已保存' implicitly separates it from mattermost_login, which presumably acquires a token. It is clear without naming a sibling explicitly.

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?

There is no explicit when-to-use or when-not-to-use statement, but 'validates the saved token' implies the natural pre-flight use case before calling other Mattermost tools. The agent must infer this rather than being told, and no alternatives are mentioned.

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