Retrieve Redmine time entries filtered by user, project, issue, or date range to review logged work hours and track project effort.
作業時間の一覧を返す(フィルタ可)。
Args: user_id: 数値 ID または "me" from_date / to_date: 期間(YYYY-MM-DD)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| to_date | No | ||
| user_id | No | ||
| issue_id | No | ||
| from_date | No | ||
| project_id | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about permissions, whether results are paginated (the limit default of 25 is never mentioned), or result ordering. It discloses only that filtering is available, which is thin for a 6-parameter read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, leading with the core action before the argument notes. It is well sized for the task, though the Args block is only partially complete rather than verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters at 0% schema coverage and no annotations, the description should do more heavy lifting; instead it covers only half the parameters and omits pagination behavior entirely. The presence of an output schema excuses it from describing return values, but the input-side gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description documents only 3 of 6 parameters (user_id, from_date, to_date), omitting limit, issue_id, and project_id entirely. It does add useful format details ('me' sentinel value, YYYY-MM-DD), but half the parameters remain undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('作業時間の一覧を返す' = returns a list of time entries), which clearly distinguishes it from the mutation siblings create/update/delete_time_entry. It does not explicitly name or contrast with any alternative, but the list-vs-mutate distinction is inherent and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(フィルタ可)' merely notes that filtering is possible; it gives no guidance on when to use this tool versus other list tools (list_issues, list_projects) or when filters are required. No prerequisites, exclusions, or conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.