get_running_timerCheck the active timer and see elapsed minutes, or confirm none is running. Use it to monitor time tracking status before logging or editing entries.
The timer that is running now, with elapsed minutes, or null when none is running.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| running | Yes | The running timer, or null |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the null-when-idle contract, which is genuinely useful behavioral context, but it discloses nothing further (no cost, no scope, no freshness). The null case is also arguably part of the return contract covered by the output 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?
A single front-loaded sentence with no filler. The most decision-relevant fact (what is returned) leads, and the edge case (null) closes it.
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 singleton lookup with a declared output schema, the description covers everything an agent needs: what it fetches, what it includes, and what happens when there is nothing to fetch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to document and the schema/description cannot conflict. Baseline of 4 applies; the description neither needs to nor attempts to explain inputs.
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 timer that is running now') and its payload ('elapsed minutes'), so an agent knows exactly what this returns. It does not explicitly contrast itself with siblings like start_timer or stop_timer, but the verb/resource combination is unambiguous enough that confusion is unlikely.
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 is only implied: an agent can infer this is the read used to check whether a timer is active before starting/stopping one. There is no explicit when-to-use statement, no mention of alternatives, and no prerequisites or side conditions called out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.