Track billable time from your AI chat: timers, entries, reports, CSV export. All data stays local.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 14 tools
Each tool targets a distinct action or resource: timer_start/timer_stop/timer_status handle the running stopwatch, entry_* manage logged entries, and report/invoice_summary/export_csv serve different output purposes. The boundaries between entry_list and report, or invoice_summary and export_csv, are clear and non-overlapping.
The majority follow a consistent noun_verb pattern (entry_add, timer_start, license_activate), and snake_case is used throughout. However, export_csv and invoice_summary break the pattern (verb_noun or noun_noun), and report stands alone without a prefix, so the consistency is strong but not perfect.
Fourteen tools is appropriate for a full-featured time tracking server: timer controls, entry CRUD, reporting/export, invoicing, rate configuration, and license management. Each tool earns its place, and the count feels neither thin nor bloated.
The core lifecycle is covered: create entries (entry_add, timer_start/stop), read/list (entry_list, report), update (entry_edit, entry_mark_billed, project_set_rate), and delete (entry_delete). Invoice-related output and export are present, but there's no explicit project/client management or unmark-billed action, though these may be intentionally left to the underlying application.
Log time already worked as one entry and return its id, duration and amount. Give start plus end or minutes. rate is hourly in MAJOR units and is frozen on the entry, so a later rate change never moves it.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ISO 8601 end time (or use minutes) | |
| note | No | Optional note | |
| rate | No | Hourly rate for this entry; a number (90) or the words the user said ('90 euros an hour') | |
| tags | No | Optional tags | |
| task | No | What the work was | |
| start | Yes | ISO 8601 start time, e.g. 2026-09-02T09:00:00 | |
| minutes | No | Duration in minutes (alternative to end) | |
| project | Yes | Project or client name. A partial name that matches exactly one existing project is used as that project. | |
| billable | No | Default true; set false for non-billable work | |
| currency | No | Currency of the rate: EUR, USD, GBP, PLN, or words like 'euros'. Defaults to the project currency, else USD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the sparse annotations, the description discloses important behavior: it returns id/duration/amount and explains that rate is frozen at creation time so later rate changes won't affect it. It also clarifies that rate is in MAJOR units, which is non-obvious. It does not cover every possible edge behavior, but it substantially exceeds what annotations alone provide.
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 convey the core behavior, return value, duration input options, and an important rate nuance with no wasted words. The most important usage constraint ('already worked') appears first, making the description easy to scan.
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 the tool has 10 parameters and no output schema, the description covers the essential calling contract: what is created, how duration is supplied, and what the caller gets back. Optional fields and defaults are already documented in the schema, so the description doesn't need to repeat them. It is slightly short on edge-case guidance (e.g., conflicts between end and minutes, or partial project matching), but the schema covers those.
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 a baseline of 3 applies. The description adds value by explaining that the rate is expressed in MAJOR units and frozen on the entry, and by clarifying that start plus either end or minutes are the ways to specify duration. This is meaningful semantic context beyond the schema field descriptions.
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 action — 'Log time already worked as one entry' — and names the resource (time entry) plus the return payload (id, duration, amount). The phrase 'already worked' differentiates it from timer-based siblings like timer_start and timer_stop, and from mutation siblings like entry_edit/entry_delete.
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 clearly says this is for time already worked rather than active tracking, and explains the two input modes: 'start plus end or minutes'. It does not explicitly name alternatives or give exclusions, but the context ('already worked') is enough to guide an agent away from timer tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one logged entry by id and report the project and hours removed. It never touches a running timer. A billed entry goes too, losing the invoice record, so correct one with entry_edit instead.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Entry id from entry_list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive, but the description adds important behavioral details beyond that: it reports project and hours removed, never touches a running timer, and deletes billed entries along with their invoice record. These are meaningful side effects the agent would not otherwise know.
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, each earning its place: the core action and result, the running-timer safety guarantee, and the billed-entry caveat with the correct alternative. It is tightly written and front-loaded.
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 simple one-parameter deletion tool with no output schema and destructive annotations, the description covers the action, the return information, the key non-effects, and the irreversible consequence. Nothing important is missing for correct invocation.
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 already fully documents the single parameter 'id' with 'Entry id from entry_list', so 100% coverage is present. The description adds 'by id' but does not meaningfully expand on the parameter meaning 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?
The description states a specific verb ('Delete'), a specific resource ('one logged entry by id'), and the observable effect ('report the project and hours removed'). It clearly distinguishes this tool from siblings like entry_edit and entry_add.
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?
The description explicitly covers when to use the tool (deleting a logged entry) and when not to: it warns that billed entries lose their invoice record and directs the agent to use entry_edit instead. This is strong usage guidance with an explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change one logged entry by id; only the fields you pass move. minutes keeps start and moves end, an end at or before start is refused, tags REPLACES the list, and rate is hourly in MAJOR units.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Entry id from entry_list | |
| end | No | ISO 8601 | |
| note | No | ||
| rate | No | Hourly rate override for this entry, a number or words like '90 euros' | |
| tags | No | ||
| task | No | ||
| start | No | ISO 8601 | |
| minutes | No | New duration in minutes, keeps start | |
| project | No | ||
| billable | No | ||
| currency | No | Currency of the rate, e.g. EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important non-obvious behavior well beyond the annotations: partial-field merge semantics, minutes moving end while keeping start, refusal of end at/before start, tags REPLACING the list, and rate units in major currency units. These are exactly the traps an agent needs to know.
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 a single dense sentence that front-loads the core purpose and then packs the critical edge-case rules without wasted words. Every clause contributes meaning.
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?
The description covers the most important update semantics, but with 11 parameters and no output schema, it leaves some ambiguities: behavior when both end and minutes are passed, clearing fields with empty values, and what happens when the id is not found. It is adequate but not fully complete for a tool this parameter-rich.
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?
With 55% schema description coverage, the description compensates by adding meaning for minutes, end/start validation, tags replacement behavior, and rate units. It does not individually explain note, task, project, billable, or currency, but their types and names are reasonably self-explanatory and currency is partially covered in 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?
The description opens with 'Change one logged entry by id', which names the verb, resource, and scope precisely. This clearly distinguishes entry_edit from siblings like entry_add, entry_delete, and entry_list.
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?
The description gives clear operating context: it edits one existing entry by id and only moves provided fields. It does not explicitly name alternatives or exclusion conditions, but the sibling set makes the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List logged entries as a table of id, day, start, project, task, hours, billable, tags and note, newest first, with total hours. Free reads the last 7 days and says so; Pro reads the whole history.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO date/time upper bound | |
| from | No | ISO date/time lower bound | |
| limit | No | Maximum rows, newest first (default 50) | |
| project | No | Filter by project name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds meaningful behavioral context beyond the annotations: the exact output columns, sort order (newest first), the inclusion of total hours, and the plan-dependent data scope. This gives the agent useful expectations without being verbose.
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 sentences, zero filler. The main behavior and output format are front-loaded, and the plan limitation is stated efficiently in the second sentence. Every clause earns its place.
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 there is no output schema, the description fully enumerates the returned fields, ordering, and the total-hours summary. It also discloses the Free vs Pro scope, which is critical for setting correct expectations. Nothing an agent needs to call this tool 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 description coverage is 100%, so all four parameters (to, from, limit, project) are documented in the schema. The description does not add parameter-specific semantics beyond the schema, which is acceptable given the full coverage. It mentions 'project' as an output column but not as a filter, so no extra value is provided.
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 ('List'), a resource ('logged entries'), and the exact output shape: a table of named columns, newest first, with total hours. This clearly distinguishes it from sibling tools like entry_add, entry_delete, and report.
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?
The description gives clear context: this tool returns a table of entries and is appropriate when that tabular view is needed. It also notes the Free vs Pro data availability limitation. It does not explicitly name alternatives like export_csv or report, but the intended use is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the loop after an invoice is issued: stamp the tracked hours that went on it with the invoice number, so report and invoice_summary stop offering them and the same hours are never billed twice.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO date/time end of the billed period, used with project | |
| ids | No | Exact entry ids, normally the entry_ids invoice_summary returned. Pass either ids or project plus from and to. Entries already billed are left alone and listed back to you. | |
| from | No | ISO date/time start of the billed period, used with project | |
| project | No | Project or client, used with from and to instead of ids; every billable entry in that range is stamped. | |
| billed_at | No | ISO timestamp of the stamp, defaults to now | |
| invoice_number | Yes | The invoice these hours were put on, e.g. INV-2026-0001 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation stamps entries with an invoice number, causing report and invoice_summary to stop offering them and preventing double billing. This adds meaningful side-effect context beyond the annotations, which only indicate the operation is not read-only and not destructive.
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 front-loaded sentence that states the purpose, mechanism, and consequences without padding. Each clause contributes directly to the agent's understanding, and there is no redundant or vague wording.
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?
The description provides the workflow rationale and effects, while the schema supplies all parameter details, including the idempotent skip-and-return behavior for already-billed entries. With no output schema and no safety annotations, this is adequate for correct invocation, though the description could more explicitly mention the two invocation modes (ids vs. project+from+to).
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 six parameters have descriptive text. The tool description itself adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 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?
The description uses a specific verb ('stamp') applied to a specific resource ('tracked hours') and explains the downstream effect on report and invoice_summary. This clearly distinguishes it from sibling entry-editing tools by tying it directly to the invoicing workflow.
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?
The opening phrase 'Close the loop after an invoice is issued' explicitly gives the trigger condition for using this tool. It does not name alternatives or exclusions, but the workflow context is clear enough that an agent can decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this tool to export the timesheet to a CSV file (excel-friendly) you can hand to a bookkeeper: one row per entry with hours, billable, rate, currency and amount. Returns the file path written.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO date/time upper bound. On the free tier the export is clamped to the last 7 days; Pro exports the full history. | |
| from | No | ISO date/time lower bound. On the free tier the export is clamped to the last 7 days; Pro exports the full history. | |
| path | No | Target file path; a relative path resolves against the working directory. Defaults to a timestamped file in the local data directory, and the full path is returned. | |
| project | No | Optional project filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing that a file is written and that the path is returned. It does not mention overwrite behavior or idempotency, but the tier-based clamping is covered in the parameter schema, so the gap is minor.
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 sentences with zero filler: the purpose is front-loaded, the output format and row content are specified, and the return value is stated. Every phrase earns its place.
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 simple export tool, the description covers the essential decision inputs: output format, row content, intended use, and return value. The parameter schema handles defaults and tier clamping. A mention of overwrite behavior would make it fully complete.
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 schema already thoroughly documents all four parameters. The description adds useful output context like row fields and the returned path, but it does not add new meaning to the parameters themselves.
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 ('export'), a clear resource ('the timesheet'), and a concrete output ('CSV file'), along with the intended audience ('bookkeeper') and the row content. It is clearly distinguishable from sibling list/report tools.
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?
The description explicitly opens with 'Call this tool to export the timesheet to a CSV file', which gives clear context for when to use it. It does not explicitly name alternatives or state when not to use it, so it stops 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.
Turn tracked billable time into invoice lines for one project: hours, hourly rate, amount per task and the total, one line per rate so two rates never average. Hours already marked billed are left out. Free: last 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ISO date/time end of the billing period. Free covers the last 7 days; Pro invoices any period from the full history. | |
| from | Yes | ISO date/time start of the billing period. Free covers the last 7 days; Pro invoices any period from the full history. | |
| project | Yes | Project or client to invoice | |
| unbilled_only | No | Default true: hours already put on an invoice (entry_mark_billed) are left out, so the same hours are never billed twice. Pass false to see the whole period including invoiced work. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral detail beyond annotations: billed hours are excluded by default and lines are grouped per rate to prevent averaging. This helps the agent understand output semantics without needing to inspect the schema.
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, each earning its place: purpose and output, billing exclusion behavior, and plan limitation. The key acting verb and resource appear first, and there is no filler or repetition beyond acceptable reinforcement.
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 read-only summary tool with four parameters and no output schema, the description covers the essential output contents and key behaviors. It could additionally state the exact response shape, but the 'invoice lines' and 'one line per rate' phrasing give enough structural expectation for an agent to proceed safely.
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 input schema already explains from/to's free vs Pro period behavior and unbilled_only's default and effect. The description mostly restates these points ('Hours already marked billed are left out', 'Free: last 7 days') rather than adding new parameter-level meaning. Baseline 3 is appropriate because the schema carries the detail.
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 starts with a specific verb and resource: turning tracked billable time into invoice lines for one project. It clearly enumerates the output fields (hours, hourly rate, amount per task, total) and adds a distinguishing behavior (one line per rate, no averaging), which separates it from sibling tools like report and export_csv.
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?
The description gives clear context: this is for one project, converts billable time into invoice lines, and covers a billing period. It does not explicitly name alternatives or say when not to use it, but the 'for one project' and 'invoice lines' framing strongly imply its niche relative to report and export_csv.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn Pro on for this connection with key, an MCPL1.. issued at checkout for this server or the bundle. Data under your token stays; a wrong or expired key changes nothing. license_status confirms it.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | License key from checkout, MCPL1.<payload>.<signature> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the operation.
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 two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential information.
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 single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent 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 already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present in 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?
The description uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.
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?
The description provides clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report this endpoint's licence state for your token as JSON: the product, the tier free or pro, why it is not Pro, and the checkout URL. Call it to explain a free-tier refusal. No arguments, nothing changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the call.
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 dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information is front-loaded.
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 sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this 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?
There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.
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 begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.
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?
The description explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the hourly rate and currency used to turn tracked hours into money for a project or client. Returns the new rate and, when re-rating is asked for, how many already logged entries changed.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project or client name. A partial name that matches exactly one existing project is used as that project. | |
| currency | No | Currency: a code (EUR, USD, GBP, PLN) or a word ('euros', 'pounds', 'zl'). Defaults to the shared business profile's default_currency, else USD. | |
| hourly_rate | Yes | Hourly rate: a number (85) or the words the user said ('90 euros an hour'). '1,200 USD' is 1200; '12,50 EUR' is 12.50; anything ambiguous is refused. | |
| only_missing | No | Only meaningful with apply_to_existing. True restores the old fill-the-gaps behaviour: only entries that carry no rate of their own are touched. Default false, which re-stamps every entry of the project. | |
| apply_to_existing | No | Re-rate time already logged for this project: every entry is re-stamped with the new rate, including entries that already carry one. Default false: the new rate applies to future entries only, because each entry captures the rate in force when it was logged. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false and destructiveHint=false, leaving the behavioral burden on the description. The description does disclose that it returns the new rate and the count of changed entries when re-rating is requested, but it does not mention the default behavior (future-only vs. apply_to_existing) or the side effects of the only_missing flag; these are left to the schema.
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 sentences, both information-dense and front-loaded with the core action. No wasted words or redundant restatements of the schema.
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 the rich schema and the description's explicit mention of return values, the tool is adequately described for an agent to call it correctly. Minor gaps like default behavior are covered by the schema, and no output schema exists so the return value note is sufficient.
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 schema already documents all five parameters. The description adds no significant meaning beyond naming 'hourly rate' and 'currency', so the baseline 3 is 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?
States a specific verb and resource ('Set the hourly rate and currency used to turn tracked hours into money for a project or client'). This clearly differentiates the tool from sibling entry-management and reporting tools without needing to open 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?
Provides clear context for when to use the tool (setting rates for projects/clients) and no exclusion is needed since no sibling tool competes for the same action. However, it does not explicitly state when not to use it or point to alternatives, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Timesheet report: total tracked hours and billable money for a period, optionally grouped by (group by) project, day, task or tag - hours per project, how much to bill. Omit group_by for the plain total per currency.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ISO date/time end of the period. On the free tier the window is clamped to the last 7 days; Pro reports over the full history. | |
| from | Yes | ISO date/time start of the period. On the free tier the window is clamped to the last 7 days; Pro reports over the full history. | |
| format | No | table (default), json or csv. Every format carries one amount per currency, never a mixed-currency sum. | |
| project | No | Optional project filter | |
| group_by | No | project | day | task | tag. Optional: omit it for the plain total per currency, with no breakdown. Money is grouped by currency and EUR is never added to USD. | |
| unbilled_only | No | Default true: hours already put on an invoice (entry_mark_billed) are excluded, so the report answers 'what is still to bill'. Pass false for the full timesheet including invoiced work. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful aggregation context: grouping by project/day/task/tag, per-currency totals, and the 'how much to bill' framing. It does not mention the free-tier clamping or the unbilled_only default, but those are present in the schema and there is no contradiction.
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 two sentences with the core purpose front-loaded and no filler. The parenthetical '(group by)' is slightly redundant, but every clause contributes meaningful information.
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 six-parameter reporting tool with complete schema descriptions and supportive annotations, the definition covers purpose, grouping options, currency behavior, and output formats. It does not fully specify the return structure, but the format enum and per-currency guarantee reduce that gap.
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 schema already documents all six parameters. The description reinforces group_by behavior and adds an illustrative 'hours per project, how much to bill' framing, but it does not substantially extend what the schema already provides.
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 clearly states the resource (timesheet report) and the outputs: total tracked hours, billable money, and how much to bill over a period, with optional grouping. It is distinct from a per-entry list and from invoice_summary by focusing on aggregated billable totals. It does not explicitly name sibling alternatives, so it stops short of a full 5.
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?
The description implies the use case: when you need totals or billable amounts for a period, use this tool, and omit group_by for a plain per-currency total. It does not explicitly state when to prefer report over siblings like entry_list, export_csv, or invoice_summary, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a stopwatch for work on a project and return the start time. Only one runs at a time: a new one stops and logs the previous, naming it. rate is an hourly rate in MAJOR units for this timer only.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | Hourly rate for this timer only; a number (90) or the words the user said, e.g. rate '90 euros an hour'. Defaults to the project rate set by project_set_rate. | |
| tags | No | Free-form tags, e.g. ['dev','meeting'] | |
| task | No | What you are working on right now | |
| project | Yes | Project or client name, e.g. 'acme-website'. A partial name that matches exactly one existing project is used as that project. | |
| currency | No | Currency of the rate: EUR, USD, GBP, PLN, or words like 'euros'. Defaults to the project currency, else USD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations set to false, the description carries the full burden of behavioral disclosure. It adds a key non-obvious behavior: starting a new timer stops and logs the previous one. This goes beyond the schema and gives the agent important side-effect information.
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 two sentences, tightly written, with the primary purpose front-loaded. Every sentence contributes meaning: purpose, behavior, and a key parameter clarification. No redundancy or 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?
The description covers the core behavior, the single-run constraint, and the return value (start time). It does not detail error handling or the exact naming convention for the logged previous timer, but these are secondary. Given the schema covers parameter specifics, the description is adequate for an agent to invoke 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 all parameters. The description adds only a clarification about 'MAJOR units' for the rate parameter, which is useful but minimal. It does not elaborate on tags, task, currency, or project beyond what the schema provides.
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 clearly states a specific action: starting a stopwatch for project work and returning the start time. It also distinguishes itself from siblings by noting that only one timer runs at a time, implying this tool supersedes any existing timer.
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?
The description implies when to use it (to start a timer) and notes that it stops the previous one, but it does not explicitly mention alternatives like timer_stop for stopping without starting, or when not to use this tool. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the running timer and today's total hours. Today is the local calendar day, so a timer started at 23:30 yesterday contributes only the minutes since midnight. No arguments, and it writes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the annotations by clarifying that 'Today is the local calendar day' and that a timer started before midnight contributes only post-midnight minutes. This edge-case behavioral detail is not present in the annotations and helps the agent interpret results correctly.
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, each with a distinct purpose: state the output, explain the calendar-day nuance, and confirm no side effects. It is front-loaded with the main function and contains no filler or redundant content.
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 read-only tool, the description fully covers what is reported, how the day boundary is handled, and that no state is changed. Annotations already cover safety, and the description supplies the operational detail needed for correct invocation and interpretation.
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 input schema has zero parameters, so there is nothing for the description to explain. The description does explicitly state 'No arguments,' which reinforces the schema and removes any doubt for the agent.
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 begins with a specific verb and resource: 'Report the running timer and today's total hours.' It clearly identifies the tool's output and distinguishes it from sibling tools like timer_start and timer_stop by emphasizing it is a status read, not a mutation.
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?
The description clearly implies when to use this tool: to check current timer state and accumulated hours. It does not explicitly name alternatives or exclusions, but the context of sibling tools and the explicit 'No arguments' and 'writes nothing' phrases effectively signal read-only usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the running timer and log it as one entry. Returns the duration, the money at the rate in force and the new entry id. With no timer running it says so and writes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional note stored with the entry |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description explains the actual effects: it logs the timer as one entry, returns duration, money, and the new entry id, and does nothing if no timer is running. This gives the agent a solid understanding of side effects and edge-case 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 short sentences front-load the core action, then cover return values and the no-timer behavior. There is no filler or redundant information.
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 simple tool with one optional parameter and no output schema, the description covers the main scenario, the return values, and the edge case where no timer is running. Nothing material is missing for an agent to invoke 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 input schema already documents the optional 'note' parameter with 100% coverage. The description does not add any extra meaning about the parameter, so it meets the baseline but provides no additional value here.
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 ('Stop'), a precise resource ('the running timer'), and the resulting action ('log it as one entry'). It also mentions the new entry id, which clearly separates it from sibling tools like timer_start, timer_status, and entry_add.
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?
The description clearly implies when to use this tool: when a timer is running and should be stopped and logged. It also covers the no-timer case by saying it writes nothing, but it does not explicitly name alternatives such as timer_start or timer_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
entry_addentry_deleteentry_editentry_listentry_mark_billedexport_csvinvoice_summarylicense_activatelicense_statusproject_set_ratereporttimer_starttimer_statustimer_stopTrack billable time from your AI chat: timers, entries, reports, CSV export. All data stays local.
Track billable time from your AI chat: timers, entries, reports, CSV export. All data stays local.
Log hours and invoice clients from your AI chat. Time tracking and invoicing for freelancers.
Time tracking and invoicing for AI agents and their humans: track, log and bill work by agent.
Add one secure layer between your agents and this server.
