Skip to main content
Glama
Sign In
solidtime-mcp

solidtime-mcp

by si-essence
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

solidtime_timer_stop

Idempotent

Stops a running timer by setting its end time. Defaults to the active time entry and current UTC time; omit confirm for a dry-run preview before executing.

Instructions

Stop a running timer by setting end. PUT .../time-entries/{timeEntry}. Defaults to the active entry. Omit confirm for a dry-run.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "solidtime_timer_stop"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoDefaults to now in UTC.
confirmNoSet to the boolean true to execute the write. Omit this field for a dry-run preview. false and the string true are rejected.
time_entry_idNoDefaults to the active timer from GET /users/me/time-entries/active.
organization_idNoOrganization UUID. Falls back to SOLIDTIME_ORGANIZATION_ID, then a single membership from GET /v1/users/me/memberships.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare this as a non-readonly, idempotent, non-destructive write, and the description adds the important behavioral detail that writes are gated behind confirm=true with a dry-run default. It does not describe what a dry-run returns or what happens if no timer is active, which are the remaining gaps.

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?

Three short sentences, front-loaded with the action, then the endpoint, then the default behavior. The telegraphic "PUT .../time-entries/{timeEntry}" truncation is slightly awkward but costs no comprehension.

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

Completeness3/5

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

With four optional params, full schema coverage, and annotations covering the write safety profile, the definition is mostly sufficient. It leaves unstated what the tool returns on success versus dry-run and whether stopping an inactive timer errors, which matters for a mutation with no output schema.

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 the schema already documents end, confirm, time_entry_id, and organization_id thoroughly. The description only restates the end default and the dry-run rule, adding no syntax or fallback detail beyond the structured fields, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Stop a running timer by setting end" names a specific verb (stop) and resource (running timer) plus the mechanism (setting end), and the endpoint path is given. It implicitly contrasts with solidtime_timer_start and solidtime_timer_active, though it never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Defaults to the active entry" tells an agent it can call this without an ID, and "Omit confirm for a dry-run" gives a clear operating rule. Missing an explicit statement of the alternative tools or the precondition that a timer must actually be running.

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