Skip to main content
Glama
Sign In

PineBill

by app.pinebill
OverviewDiscussionsAdmin

Start, pause, or stop a task timer

control_task_timer

Start, pause, resume, or stop the time-tracking timer on a task. Pausing and stopping both add the elapsed time to the task's tracked total; use pause for a break and stop when the work is done. Use list_tasks to find the task ID, and list_running_timers to see which timers are already running.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "taskId": "<taskId>",
      "action": "<action>"
    },
    "name": "control_task_timer"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesstart/resume begin counting; pause/stop end the current stretch
taskIdYesTask ID (from list_tasks)

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only say this is not read-only, not destructive, not idempotent, and closed-world; the description adds genuinely new behavior by stating that pausing and stopping both commit elapsed time to the task's tracked total. That is the key side effect an agent could not infer from the annotations. It stops short of covering edge cases such as starting a timer that is already running or calling pause with no active stretch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action list, then the pause/stop distinction, then the prerequisite lookups. No restated name or filler, and each sentence carries decision-relevant information.

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

Completeness4/5

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

For a two-parameter state-mutating tool with no output schema, the definition covers what it does, how actions differ in side effect, and how to obtain the required ID. The only gap is failure behavior (e.g., starting an already-running timer), which the reference to list_running_timers partially mitigates.

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 description coverage is 100%, so both taskId and the action enum are already documented, including the start/resume-vs-pause/stop grouping. The description's added value beyond the schema is limited to clarifying pause versus stop, which the schema does not state. Baseline 3 is appropriate given the schema does the heavy lifting.

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?

The description opens with a specific verb set and resource: 'Start, pause, resume, or stop the time-tracking timer on a task,' and enumerates all four supported actions, which also matches the action enum. It is clearly distinguishable from siblings like list_running_timers (read-only listing) and adjust_task_time (manual correction).

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?

It explicitly resolves the most likely ambiguity between two similar actions: 'use pause for a break and stop when the work is done.' It also directs the agent to list_tasks for the task ID and list_running_timers to check current state before acting, giving both prerequisites and alternatives.

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

All PineBill toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources