Skip to main content
Glama

Who am I in mite

mite_whoami
Read-only

Identify the connected account and API-key user, including role, server mode, and enabled tools to confirm permissions before making calls.

Instructions

Shows the mite account, the user behind the API key and its role, plus the mode and tools this server offers. Call it first to learn what you are allowed to do; for projects use mite_list_projects, for customers mite_list_customers. Returns account name, title and currency, the user id, name and role, and the server mode with the names of all enabled tools. Takes no input and is available in every mode.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds non-obvious context beyond that: it takes no input, is available in every server mode, and returns a specific set of fields (account name, title, currency, user id, name, role, mode, enabled tool names). It doesn't discuss auth or rate limits, but for a zero-argument introspection call this is close to complete.

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?

Three sentences, front-loaded with what the tool shows, then when to call it, then what it returns. The final sentence restates the field list already implied by the opening sentence, which is mild duplication, but it does so with more specificity (field names) and the whole thing stays short and scannable.

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

Completeness5/5

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

There is no output schema, so the description carries the burden of explaining return values, and it does so concretely: account name, title, currency, user id, name, role, server mode, and enabled tool names. Combined with the no-input and every-mode notes, an agent has everything needed to call it correctly.

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

Parameters4/5

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

The tool has zero parameters, which is the baseline-4 case. The description confirms "Takes no input," so the agent won't hunt for filtering options, but there is nothing more to explain about parameters.

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 a precise set of resources: the mite account, the API-key user and role, the server mode, and the enabled tools. It also names sibling tools that handle projects and customers, so the agent can distinguish it from `mite_list_projects` and `mite_list_customers` without reading their schemas.

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

Usage Guidelines5/5

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

Explicitly says "Call it first to learn what you are allowed to do," which gives a concrete ordering rule. It also routes the agent away from this tool to `mite_list_projects` and `mite_list_customers` for those resources, so both when to use it and when not to are covered.

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