mf_expense_auth_status

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

No annotations are provided, so the description carries the full behavioral burden, and it adds essentially nothing beyond the name: it does not say whether the call is read-only, what statuses can be returned (authenticated vs. expired vs. absent), whether it triggers or refreshes anything, or whether it has side effects. For a no-annotation tool this is a meaningful disclosure gap, though the name itself signals a passive status check.

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 with zero filler, and the core action (status check) is front-loaded. Nothing wasteful is present.

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 is the only source of information. It confirms the tool's subject but leaves the returned status vocabulary and the correct next step on failure unspecified, which is barely adequate for a minimal status-check 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?

The tool takes zero parameters, so the schema is trivially complete and no parameter meaning needs to be conveyed. Baseline for a parameterless tool is 4.

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 and resource: checking the authentication status of the expense API (経費API認証状態を確認します). This clearly distinguishes it from the generic mf_auth_status and from mf_accounting_auth_status via the '経費' (expense) qualifier. It lacks any explicit sibling differentiation statement, but the naming/scope makes the purpose unambiguous.

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 is implied: an agent would call this to verify whether expense API credentials are valid, presumably before invoking expense operations or after mf_expense_auth_start/mf_expense_auth_callback. However, the description names no prerequisites, no follow-up action when unauthenticated, and no alternative tool (e.g., mf_expense_auth_start) to route to. This is implied rather than stated guidance.

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