Skip to main content
Glama
Stefan39

mite

by Stefan39
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Hours and revenue grouped by up to three levels

mite_report
Read-only

Generate aggregated time tracking reports grouped by up to three dimensions to summarize hours, revenue, and share of hours for any period.

Instructions

Aggregated report from mite: hours, revenue and share of hours, grouped by 1 to 3 of customer, project, service, user, day, week, month, year for a period, on the mite server so whole years work. For the fixed project-by-month view use mite_report_projects_by_month, for billable share use mite_report_billable_ratio, for budgets use mite_report_budget. Returns rows with hours, revenue in currency units (null without rates) and share of hours in percent, plus a total. Read-only, no paging, default period is this year.

Input Schema

NameRequiredDescriptionDefault
toNoEnd of the period: a date as YYYY-MM-DD (e.g. 2026-03-31) or a keyword (today, yesterday, this_week, last_week, this_month, last_month, this_year, last_year). Default: today when only from is a date; without from the period is just this date.
fromNoStart of the period: a date as YYYY-MM-DD (e.g. 2026-01-01) or a keyword (today, yesterday, this_week, last_week, this_month, last_month, this_year, last_year). A keyword alone selects that whole period and ignores the end of it; a date alone runs up to today. Default: this_year (when from and to are both omitted).
user_idNoOnly these users: list of mite user ids, e.g. [7]. Needs an API key that may see other users. Default: all users the key may see.
billableNotrue = only billable entries, false = only non-billable entries. Default: both.
group_byYes1 to 3 distinct values from: customer, project, service, user, day, week, month, year, e.g. ["customer", "month"]. Required; the order sets the column order.
project_idNoOnly these projects: list of mite project ids, e.g. [789]. Default: all projects.
service_idNoOnly these services: list of mite service ids, e.g. [42]. Default: all services.
customer_idNoOnly these customers: list of mite customer ids, e.g. [123, 456]. Default: all customers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.0.1
    • changedInput schema / properties / billable / description
      Previous value: -"true = only billable, false = only non-billable."New value: +"true = only billable entries, false = only non-billable entries. Default: both."
    • changedInput schema / properties / customer_id / description
      Previous value: -"Only these customers."New value: +"Only these customers: list of mite customer ids, e.g. [123, 456]. Default: all customers."
    • changedInput schema / properties / from / description
      Previous value: -"Start date (YYYY-MM-DD) or a keyword such as this_month. Default: this_year."New value: +"Start of the period: a date as YYYY-MM-DD (e.g. 2026-01-01) or a keyword (today, yesterday, this_week, last_week, this_month, last_month, this_year, last_year). A keyword alone selects that whole period and ignores the end of it; a date alone runs up to today. Default: this_year (when from and to are both omitted)."
    • changedInput schema / properties / group_by / description
      Previous value: -"1 to 3 distinct values from: customer, project, service, user, day, week, month, year."New value: +"1 to 3 distinct values from: customer, project, service, user, day, week, month, year, e.g. [\"customer\", \"month\"]. Required; the order sets the column order."
    • changedInput schema / properties / project_id / description
      Previous value: -"Only these projects."New value: +"Only these projects: list of mite project ids, e.g. [789]. Default: all projects."
    • changedInput schema / properties / service_id / description
      Previous value: -"Only these services."New value: +"Only these services: list of mite service ids, e.g. [42]. Default: all services."
    • changedInput schema / properties / to / description
      Previous value: -"End date (YYYY-MM-DD) or a keyword. Default: the end of the period given in from."New value: +"End of the period: a date as YYYY-MM-DD (e.g. 2026-03-31) or a keyword (today, yesterday, this_week, last_week, this_month, last_month, this_year, last_year). Default: today when only from is a date; without from the period is just this date."
    • changedInput schema / properties / user_id / description
      Previous value: -"Only these users (needs a key that may see other users)."New value: +"Only these users: list of mite user ids, e.g. [7]. Needs an API key that may see other users. Default: all users the key may see."
  2. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools