Skip to main content
Glama
Sign In
solidtime-mcp

solidtime-mcp

by si-essence
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

solidtime_time_entries_bulk_update

Idempotent

Update multiple time entries by ID in one call, preview changes as a dry-run, then confirm to apply irreversible edits.

Instructions

Update many time entries. PATCH .../time-entries. Irreversible for the listed ids. 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": {
      "ids": "<ids>"
    },
    "name": "solidtime_time_entries_bulk_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
idsYes
tagsNo
typeNo
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
billableNo
member_idNo
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 readOnlyHint=false and idempotentHint=true, but they say nothing about gating or permanence; the description adds that omitting confirm yields a dry-run and that the change is irreversible for the listed ids. Note the mild tension between "irreversible" and destructiveHint=false, though an in-place field overwrite is not data deletion, so this is not a true contradiction. It does not disclose what happens to fields not supplied (e.g., whether omitting tags leaves them intact).

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, no filler, with the destructive scope and the dry-run escape hatch front-loaded. The raw "PATCH .../time-entries" fragment is mildly redundant with the tool name but cheap and aids the mental model.

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?

For a 10-parameter bulk mutation with no output schema and 20% schema coverage, the description covers the safety story (dry-run, irreversibility) but leaves most parameter behavior undefined. An agent could fire this correctly only by guessing what each optional field does to existing entry data.

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 description coverage is only 20% — just confirm and organization_id are documented there — so the description needs to compensate and does not. It never explains the semantics of ids, tags, type, billable, member_id, project_id, task_id, or description, particularly whether assigning tags replaces or merges and whether null clears a field. Only the dry-run behavior of confirm is elaborated.

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?

"Update many time entries" gives a specific verb and resource and the word "many" distinguishes it from the single-record sibling solidtime_time_entry_update. The PATCH endpoint reference reinforces that this is a mutation, but the sibling is never named explicitly, so differentiation relies on the reader inferring singular vs. bulk.

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?

"Omit confirm for a dry-run" is a genuinely useful invocation cue that tells the agent how to preview before committing. There is no guidance on when to prefer this over solidtime_time_entry_update or bulk_delete, nor on limits such as the 500-id cap being a reason to batch.

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