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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds the returned field set (date, hours, revenue, billable/locked flags, relations, note) and the specific failure mode ('not found' when the id doesn't exist). What's missing is any mention of auth/permission requirements or how the null revenue case should be interpreted beyond 'null if none'.

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?

One compact sentence with the primary action front-loaded, then the routing rule, then return shape, then failure behavior. Every clause carries information an agent would otherwise have to guess.

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 the description compensates by enumerating the returned fields and the error case. For a single-parameter read tool with annotations covering safety, nothing an agent needs to call it correctly is missing.

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?

Schema coverage is 100% and the single `id` parameter is fully documented in the schema, including type, bounds and an example. The description only restates 'by its id', so it adds no semantics beyond the structured field — baseline 3 applies.

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?

States a specific verb and resource ('Fetches one time entry from mite by its id') and immediately contrasts with the list sibling, so an agent can distinguish it from `mite_list_time_entries` without opening either schema.

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?

Gives an explicit selection rule: use this when the id is known, otherwise use `mite_list_time_entries`. The alternative and the condition that selects it are both named.

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

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 covered. The description adds genuinely useful behavior beyond that: which fields come back (id, name, archived, note) and that the whole list is returned at once with no paging — a real operational detail an agent must plan around. It omits auth requirements and ordering, keeping it below 5.

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?

Three short sentences, front-loaded with purpose and followed by usage, return shape, and paging behavior — no filler. The middle clause ("active ones or with `archived: true` the archived ones") is slightly awkward in construction but not wasteful.

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, so the description's field list (id, name, archived, note) plus the no-paging disclosure cover what an agent needs to consume the result. For a single-optional-param read tool with annotations present, the remaining gaps (ordering, auth) are minor.

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?

Schema coverage is 100% and the `archived` parameter already documents its default and effect, so the schema carries the load. The description's phrasing ("active ones or with `archived: true` the archived ones") restates the same semantics rather than adding format or edge-case detail, making 3 the appropriate baseline.

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?

States a specific verb and resource ("Lists customers from mite") and immediately scopes it to active vs. archived, which distinguishes it from the other list_* siblings that target projects, services, users, and time entries. An agent knows exactly what it fetches without opening the schema.

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?

Explicitly tells the agent when to reach for it: to look up customer ids for filters like `customer_id` in `mite_list_time_entries`, which is a concrete downstream use and cross-references a sibling. It does not name a when-not condition or an alternative source for customer data, so not quite a 5.

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

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

Annotations already declare readOnly and openWorld, so the safety profile is covered. The description adds genuinely non-obvious behavior: the full list is returned without paging, and `budget` is expressed in `budget_type` units rather than hours or currency. That is useful context beyond annotations, though pagination absence is stated only in passing.

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?

Front-loaded with the tool's identity and scope, then purpose routing, then return shape. Every sentence carries information an agent needs; nothing is redundant.

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, but the description enumerates the returned fields and explains the `budget`/`budget_type` relationship. Combined with the no-paging note, an agent has enough to call and interpret the tool correctly.

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?

Schema coverage is 100%, so the schema already documents the single `archived` parameter. The description still reinforces the default-vs-archived semantics in plain terms, marginally improving over the schema but not adding new syntax.

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?

States a specific verb and resource ('Lists projects from mite') and immediately names the scope switch (active vs. archived). It explicitly separates itself from `mite_report_budget`, so an agent can choose between the two without opening schemas.

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?

Gives a concrete use case (look up project ids for `project_id` filters in `mite_list_time_entries`) and an explicit exclusion with the correct alternative for budget usage (`mite_report_budget`). The when-to-use and when-not-to-use are both present.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real value beyond that by disclosing the returned fields (id, name, billable flag, archived flag, note) and the fact that the full list comes back unpaged. No auth or rate-limit notes, but nothing misleading.

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?

Three compact statements: what it lists, why to use it, and what comes back – front-loaded with the purpose. Slightly dense semicolon phrasing, but every clause carries information and there is no filler.

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 one-optional-parameter read tool with no output schema, the description supplies return fields and pagination behavior, which is everything an agent needs to call and interpret it. Annotations carry the safety profile.

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?

Schema description coverage is 100% and the single `archived` parameter is fully documented there with its default. The description restates the active-vs-archived behavior, which reinforces but does not add new syntax or edge-case semantics beyond the schema.

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?

Specific verb plus resource ('Lists services (activity types) from mite') with the scope spelled out as active vs archived. The parenthetical synonym 'activity types' removes domain ambiguity, and the tool is clearly distinguishable from sibling list tools like mite_list_customers or mite_list_projects.

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?

Explicitly says to use it to look up service ids for filters such as `service_id` in `mite_list_time_entries`, which routes the agent to the right downstream tool. It stops short of naming a when-not case, but there is no competing services tool in the sibling set, so the guidance is practically complete.

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

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

Beyond the read-only annotations, the description discloses ordering, returned row fields, revenue nullability, the locked flag, pagination behavior with `limit` and `has_more`, and the default reporting period. This is substantive behavioral context not present in the annotations.

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?

The description is dense but front-loaded: purpose and routing come first, then return shape and pagination details. Every sentence contributes either selection guidance or invocation-relevant behavior.

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?

With ten optional parameters and no output schema, the description supplies the missing return-shape and pagination information an agent needs. It also explains the period default, so the tool can be invoked correctly even with no arguments.

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?

Schema coverage is 100%, so all ten parameters are already documented, including the date keyword semantics and the `user_id` visibility caveat. The description summarizes filters and pagination defaults but adds little parameter meaning beyond the schema, making the baseline 3 appropriate.

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 ('Lists single time entries'), the ordering ('newest first'), the filtering dimensions, and explicitly contrasts itself with `mite_report` and `mite_get_time_entry`. An agent can distinguish this from the reporting siblings without inspecting schemas.

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?

It gives explicit use cases ('find individual entries or their ids') and names the alternatives: totals should use `mite_report`, and a known single entry should use `mite_get_time_entry`. The routing decision between sibling tools is unambiguous.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the returned fields (id, name, role, archived flag), explicitly excludes email addresses and hourly rates, and notes the whole list comes back without paging — a real behavioral constraint an agent would otherwise have to discover by trial.

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 dense sentence whose clauses each carry distinct information: scope, cross-reference, return shape, exclusions, and pagination. Purpose is front-loaded and there is no filler.

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?

With only one fully-documented optional parameter and no output schema, the description covers everything an agent needs: what is returned, what is deliberately omitted, and that no pagination handling is required.

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?

Schema coverage is 100% and the schema already documents `archived` with its default and meaning. The description's 'active ones or with `archived: true` the archived ones' restates the same semantics rather than adding format or edge-case detail, so the baseline 3 applies.

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?

States a specific verb and resource ('Lists users from mite') plus the scope switch (active vs. archived). It explicitly distinguishes itself from mite_whoami, which returns the current user, so an agent can separate it from that sibling without opening a schema.

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?

Gives a concrete use case ('look up user ids for `user_id` in `mite_list_time_entries`') and names the alternative for the current-user case ('`mite_whoami` for the current user'). When-to-use and when-not-to-use are both present with named siblings.

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

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

Adds real context beyond the readOnlyHint/openWorldHint annotations: aggregation happens server-side so multi-year ranges work, there is no paging, revenue comes back null when rates are missing, and the default period is this year. It does not mention auth scope beyond group filtering or response size limits, so it stops short of fully transparent.

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?

Front-loaded with the purpose and grouping, then alternatives, then return shape and defaults. The first sentence is long and packs grouping values that the schema already enumerates, but nothing is pure filler.

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?

No output schema exists, and the description compensates by naming the returned columns (hours, revenue in currency units, share of hours in percent) plus a total row. Combined with the period default and no-paging note, an agent has everything needed to call and interpret it.

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?

Schema coverage is 100% and every parameter already carries a detailed description including defaults and keyword periods, so the baseline is 3. The description restates the group_by enumeration and the default period but adds no new parameter semantics such as how filters interact with the grouping.

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?

States a specific verb and resource ('aggregated report of hours, revenue and share of hours') plus the core grouping mechanic (1 to 3 of customer/project/service/user/day/week/month/year). It is immediately distinguishable from the fixed-shape siblings it names.

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?

Explicitly routes to three named alternatives with the condition that selects each: fixed project-by-month view, billable share, and budgets. An agent can pick the right tool without opening any schema.

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

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

Beyond the `readOnlyHint`, the description provides several vital operational constraints, including 'no paging,' the precise output format ('hours and a ratio in percent with one decimal'), and the 'default period is this year.'

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?

The definition is extremely concise. It packs the resource name, core metrics, aggregation level, operational constraints, and sibling differentiation into a tightly written, single block of text.

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?

Given that the schema is complete (100% coverage), the description covers all remaining high-value information: aggregation level, output formatting (one decimal), lack of pagination, and default temporal scope.

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?

While the schema covers the parameter types, the description adds semantic value by confirming the granularity of the output (per group and as a total) and the default scope of the period (this year).

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 highly specific, stating it reports 'billable hours, non-billable hours and the billable share in percent.' Furthermore, it clearly differentiates itself from the general 'mite_report' sibling by specifying the focus on billability ratios.

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 guidance is excellent because it provides a direct comparative rule: 'For revenue or other groupings use `mite_report`.' This gives the agent an explicit alternative choice for related queries.

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

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

Goes well beyond the readOnly/openWorld annotations: it explains unit conventions (minute budgets in hours, cent budgets as currency), that consumption equals revenue for budgeted projects, that budget/remaining/percent are null for unbudgeted projects, and that results are not paged. These are the exact semantic traps an agent could misread from raw numbers.

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?

Dense but front-loaded: the core definition comes first, then the sibling disambiguation, then unit/null caveats, then the default. Every clause carries information; nothing is filler.

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?

With no output schema, the description does the work of listing returned fields, their units, and null conditions. The one minor gap is the numeric convention for 'percent used' (0-100 vs 0-1), which an agent would still have to infer from the response.

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?

Schema description coverage is 100%, so the baseline is 3. The description restates the default ('Without project_id: all active projects with a budget') and partly duplicates the schema's own parameter description rather than adding new syntax or format details.

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?

Names the exact resource (budget, consumption, remaining, percent used per project) and scopes it to whole project life rather than a period. It also names the sibling `mite_report` as the tool for the period-based case, so the agent can distinguish the two without opening the schemas.

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?

Explicit routing: 'for hours or revenue in a period use `mite_report`'. It also states default behavior when project_id is omitted ('all active projects with a budget'), so there is no ambiguity about when and how to call it.

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

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

Annotations already declare readOnlyHint, but the description adds real value beyond them: it discloses the return shape (rows of month/project/hours/revenue plus total), that revenue is null without rates, that there is no paging, and that aggregation happens server-side. Only minor gaps remain, e.g. exact currency handling or empty-result behavior.

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?

Three dense sentences, front-loaded with what the tool does, then sibling routing, then return/behavior notes. Each clause carries information; nothing is redundant.

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?

Despite having no output schema, the description fully specifies the return rows and the null-revenue caveat, and it covers period defaults and read-only/no-paging behavior. An agent has everything needed to call and interpret the result.

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?

Schema description coverage is 100%, so all seven parameters (including date keywords, list filters, and the billable flag) are already documented in the schema. The description only echoes the default period and return semantics, adding marginal parameter-level detail beyond structured fields, so baseline 3 applies.

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?

States a specific verb+resource+scope: 'hours and revenue per project and month for a period,' with the key distinguishing trait (grouping done server-side so whole years work). It explicitly names the sibling tools it is not (mite_report for other groupings, mite_list_time_entries for single entries), so an agent can route without opening schemas.

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?

Gives explicit when-to-use-this vs alternatives: 'For other groupings or totals use `mite_report`; for single entries use `mite_list_time_entries`.' The condition selecting each tool is stated, leaving nothing to inference.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description reinforces read-only status while adding valuable behavior the annotations don't: the exact response shape (`running`, `time_entry_id`, `since`, `minutes`, cumulative total) and the scope of 'the key's user'. It does not cover error/edge behavior when the tracker is stopped beyond implication, so not a 5.

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?

Two tightly written sentences, front-loaded with the primary question (is it running), followed by return fields and the sibling routing hint. No wasted clauses.

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?

With no output schema, the description carries the burden of explaining return values and does so precisely, listing each field and its meaning. Combined with the no-input and read-only statements, 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.

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

The schema has zero parameters, so the baseline is 4; the description correctly states it takes no input, confirming what the empty schema implies. No additional parameter meaning is needed.

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 names a specific resource (the mite time tracker) and a specific question it answers (running or not, and on which entry), plus the exact returned fields. An agent can distinguish it from listing tools or get_time_entry without opening any schema.

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?

It states the tool takes no input and is read-only, and explicitly routes the agent to `mite_get_time_entry` for full entry details. There is no explicit 'when not to use' beyond that routing, so it falls just short of a 5.

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

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.

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.

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.

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.

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.

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.