whoami

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

No annotations are provided, so the description carries the whole burden, and it discloses almost nothing behavioral: it does not say whether the call is read-only (implied but unstated), whether it requires an existing session, what happens if unauthenticated, or whether it can trigger a login. The content it does give is essentially a return-value summary, which duplicates the output schema rather than adding behavioral context.

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?

At seven words it is certainly concise and front-loaded, but conciseness here tips into under-specification: a bare noun phrase with no verb leaves the action ambiguous. No words are wasted, but the words present do not do enough work for an agent to be confident about the tool's effect.

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 informational tool with an output schema, the description need not explain return values, and the schema plus the field list cover that half of the picture. What is missing is the operational context that matters for a session-scoped call: whether a logged-in session is required and how this differs from the environment/login siblings. Adequate but with clear gaps.

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 per the baseline this scores 4; there is no parameter meaning the description could add. Nothing in the description misrepresents the argument surface, and the empty schema is consistent with a no-argument context lookup.

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 is a noun fragment ('Active SAP system, host, client and user') that reads like a list of return fields rather than a statement of what the tool does. Combined with the name whoami, an agent can infer it reports the current session's identity and environment, but the description never supplies a verb or states that this is a session-context read. It does implicitly distinguish itself from mutating siblings such as switch_environment and sap_login, but only by omission.

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 when-to-use guidance at all: nothing tells the agent to call this to confirm which system/client/user is active before running reports or queries. No contrast is drawn with adjacent siblings like list_environments, switch_environment, or sap_login, which an agent could easily confuse with a session-identity check. Usage must be fully inferred.

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