timelog_update_entryUpdate fields on a draft/rejected time entry. Pass employee_id to move the entry to another employee (requires time approval rights).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| note | No | ||
| hours | No | ||
| employee_id | No | Reassign the entry to another employee. Requires 'time.approve' or full Time Tracking data scope. | |
| is_billable | No | ||
| time_entry_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is not read-only and not destructive. The description adds useful behavioral context: only draft/rejected entries can be updated, and passing employee_id moves the entry to another employee with a permission requirement. This goes beyond the structured annotations and does not contradict them.
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 two sentences with no filler. The core purpose and status restriction are front-loaded, and the special employee_id behavior is stated in the second sentence. Every part earns its place.
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?
The core purpose and the special reassignment case are covered, but with six parameters, low schema coverage, and no output schema, an agent still lacks guidance on field value semantics and any post-update behavior. It is adequate for a simple update tool but has clear gaps.
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 only 17%, so the description should compensate for undocumented parameters. It explains employee_id behavior but leaves date, note, hours, and is_billable to inference from their names. Accepted date formats, whether hours replaces existing values, and other field semantics are not clarified.
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: 'Update fields on a draft/rejected time entry.' This clearly identifies the tool as a mutation for time entries and distinguishes it from siblings like timelog_approve_time, timelog_delete_entry, and timelog_update_expense. The draft/rejected qualifier adds precision beyond the title.
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 description explicitly limits usage to draft/rejected time entries, which implies it should not be used on approved entries. It also gives a conditional usage rule for employee_id, noting that reassignment requires time approval rights. It does not name alternative tools explicitly, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools follow a clear resource+action pattern and the descriptions are unusually precise about boundaries. A few near-overlaps remain: projects_get_finance vs projects_get_financials, and notes_create vs crm_log_activity on a deal are both plausible for recording a note on a deal.
The domain_prefix_action convention is consistent across nearly all tools, e.g. crm_create_lead, projects_update_risk, timelog_approve_time. Deviations include standalone list_trash, meta tools like whoami/tool_search/tool_invoke, and the confusing projects_get_finance/projects_get_financials pair.
With 105 tools, this far exceeds the 50+ threshold defined as an extreme mismatch. Even for a full ERP/CRM suite, the fine-grained split—39 project tools alone—creates a massive tool-selection surface that is hard for an agent to navigate reliably.
The surface covers CRM, projects, tasks, time/expenses, HR, notes, notifications, contracts, and reporting with create/read/update/delete for most primary entities. Minor gaps exist: crm_log_activity has no read-back path, contracts lack delete/restore, and proposals are intentionally read-only, but agents can work around these.