Skip to main content
Glama

reopen_timesheet

Reopen a Submitted or Approved timesheet period for corrections. The period and its time reports revert to Rejected (editable), allowing the reporter to edit and resubmit. Use this when an approved period needs fixing. An optional comment can be provided. Use confirm=true to proceed. Requires Manager or Admin/Owner role (Finance is excluded — timesheet approval is PM work, not finance).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commentNoOptional comment explaining why the period is being reopened. Shown to the reporter.
confirmNoSet true to perform the action. Omit or false returns a preview only — nothing is written.
idempotency_keyNoOptional caller-supplied key; retrying with the same key returns the original result instead of acting twice.
submission_period_idYesId of the submission period to reopen (from get_pending_approvals or list_approval_history).

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the burden. It discloses that the action reverts the period to Rejected and requires confirm=true for execution; preview otherwise. However, it does not cover idempotency or side effects like notifications.

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?

The description is front-loaded with the main action and state change, followed by usage, role, and confirmation. At 6 sentences, it is concise and avoids unnecessary details.

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 simple mutation tool with no output schema, the description covers the core action, state change, role requirement, and preview behavior. It is mostly complete, though it lacks mention of idempotency behavior.

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 coverage is 100%, so baseline is 3. The description adds minimal meaning beyond the schema, noting that comment is optional and confirm triggers the action. No new parameter context is provided.

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 clearly states the tool reopens a Submitted or Approved timesheet period for corrections, with specific verb and resource. It distinguishes from sibling tools like reject_timesheet by indicating the period reverts to Rejected state.

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?

It advises when to use ('when an approved period needs fixing') and specifies required roles (Manager or Admin/Owner, excluding Finance). It also mentions the confirm=true requirement for execution, providing clear context.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3/5.0
Disambiguation2/5

Multiple tools have overlapping purposes, e.g., create_time_report and log_time both create a single time entry with near-identical descriptions. There are also many similar getter/list tools that blur together, making it hard for an agent to select the right one.

Naming Consistency2/5

Most tool names use snake_case, but verbs are inconsistent: 'list' vs 'get' for similar operations, 'manage' combines create/update/delete, and 'use_favorite' is an outlier. This pattern reduces predictability.

Tool Count1/5

With 114 tools, the set is extremely large and far beyond a well-scoped server (typical 3-15). This overwhelms agents and suggests many tools could be consolidated or removed.

Completeness3/5

The tool surface covers a broad domain including customers, projects, tasks, time tracking, invoicing, and user management, but there are gaps like no list_users or direct user listing, and some operations seem redundant rather than filling missing functionality.

Resources