Skip to main content
Glama

Log work time

entry_log

Log work time for a client/project in one step: minutes worked plus an optional note. The entry starts now minus the minutes, so it lands on today's day and week summaries.

Input Schema

NameRequiredDescriptionDefault
noteNoOptional note
clientYesClient or project name. A partial name matching exactly one project resolves to it.
minutesYesMinutes of work to log
projectNoSub-project or task label stored on the entry

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Added

TDQS

A3.8/5.0
Behavior4/5

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

The annotations already disclose that this is a non-read-only, non-destructive, non-idempotent, closed-world operation. The description adds meaningful behavioral context by explaining that the entry timestamp is calculated as now minus the minutes and that it affects today's day and week summaries.

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?

The description is two compact sentences with no wasted wording. It front-loads the core action and follows with the important timestamp behavior.

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 time-entry mutation tool with full schema coverage and annotations, the description covers the main action and a key side effect. It could be more complete by mentioning how it relates to entry_add/entry_edit or what the call returns, but the essentials are present.

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 client, minutes, note, and project. The description mentions minutes and the optional note but adds little parameter-specific meaning beyond what the schema provides.

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?

The description states a specific verb and resource: logging work time for a client/project with minutes and an optional note. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as entry_add or entry_edit.

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?

The phrase 'in one step' implies a quick logging workflow, but the description never explicitly says when to use this tool instead of entry_add or entry_edit. Usage is implied rather than stated through alternatives or exclusions.

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.