gryzzly-mcp

timesheet

Read-only

Summarize logged time over a week or period by day and project, showing totals, project shares, and days below expected hours. Use it to see what was logged or missing.

Instructions

Summarise declared time over a week or a period for one user, the current one by default: totals per day and per project, each project's share, and the working days below the expected hours. Use it to answer how much was logged or what is missing; use list_time_entries when you need the individual entries and their ids. Read-only. Optional project and task filters narrow the totals, not just a listing.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	Last day of an explicit period. Defaults to `from`.
`from`	No	First day of an explicit period. Ignored when `week` is set.
`task`	No	Keep only this task, by name or id.
`user`	No	Whose time to read. Defaults to the user this server acts as.
`week`	No	A week: `this week`, `last week`, `2026-W38`, or a date inside it.
`project`	No	Keep only this project, by name, code or id.
`expected_hours_per_day`	No	Hours expected on a working day, used to list the days that fall short. Defaults to 7.

Output Schema

TableJSON Schema

Name	Required	Description
`to`	Yes	Last day of the period.
`days`	Yes	One line per day that carries time.
`from`	Yes	First day of the period.
`user`	Yes	Whose time this is.
`week`	No	The ISO week, when the period is exactly one.
`total`	Yes	The same, human readable.
`entries`	No	The declarations themselves, when the caller asked for them.
`projects`	Yes	One line per project, largest first.
`total_hours`	Yes	The same, in decimal hours.
`total_seconds`	Yes	Declared time over the period, in seconds.
`missing_workdays`	Yes	Working days of the period with nothing declared.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the 'Read-only' line is largely redundant. However the description adds real behavioral context beyond the schema: project/task filters narrow the *totals* rather than acting as a listing filter, and the default subject is the acting user.

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?

Front-loaded with the summary behavior before the routing hint and the read-only/filter caveats. Efficient overall, though the trailing filter clarification is a slightly dense clause that could be trimmed.

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

Completeness5/5

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

An output schema exists so return values need no elaboration, annotations carry the safety profile, and the description still covers scope, defaults, filter semantics, and sibling routing. Nothing needed to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the 3-baseline applies, but the description genuinely adds meaning the schema lacks: that the project/task filters restrict the aggregation itself, not merely a listing, and that the target user defaults to the server's own identity.

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?

States a specific verb (Summarise) and resource (declared time) and enumerates the exact outputs: totals per day, per project, each project's share, and shortfall days. It explicitly distinguishes itself from list_time_entries, so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Gives two positive use cases (how much was logged, what is missing) and names the alternative tool with the condition that selects it ('when you need the individual entries and their ids'). Nothing is left to inference.

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