Skip to main content
Glama
Sign In
solidtime-mcp

solidtime-mcp

by si-essence
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

solidtime_timer_start

Start a Solidtime timer by creating an open time entry; omit confirm for a dry-run preview and set confirm to true to execute.

Instructions

Start a timer by creating a time entry with end=null. POST .../time-entries. Omit confirm for a dry-run.

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": {
      "member_id": "<member_id>",
      "billable": "<billable>"
    },
    "name": "solidtime_timer_start"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagsNo
typeNo
startNoDefaults 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.
task_idNo
billableYes
member_idYes
project_idNo
descriptionNo
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

B3.3/5.0
Behavior4/5

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

Annotations already declare the write/non-idempotent profile, and the description adds the important behavioral fact that the default call is a dry-run unless confirm is set, plus the end=null semantics that make this a timer. It does not mention duplicate-timer behavior or error cases when a timer is already active.

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 core mechanism before the dry-run caveat. The raw 'POST .../time-entries' fragment is mildly redundant with the tool's purpose but not wasteful.

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

Completeness2/5

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

A 10-parameter mutation tool with no output schema and low schema coverage needs more than three sentences. Nothing explains what the dry-run preview returns, what a successful start yields (entry id?), or how conflicts with an already-running timer are handled.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 30% and the description only reinforces confirm (already documented in the schema) and the implied end=null. It adds no meaning for member_id, billable, type, tags, task_id, project_id, or organization_id — six of the ten parameters remain unexplained.

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?

States a specific verb (start) plus the mechanism (creating a time entry with end=null) and the endpoint, which lets an agent distinguish it from solidtime_time_entry_create. It stops short of explicitly naming that sibling as the alternative for completed entries.

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

Usage Guidelines3/5

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

Gives one concrete usage rule — omit confirm for a dry-run — which is genuinely useful for a write. However, it says nothing about when to use this versus solidtime_time_entry_create or what to do if a timer is already running (solidtime_timer_active), leaving the main selection decision to inference.

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