Tradify MCP server

Overview Schema Source Related Servers Discussions Admin

Log time

log_time

Records a timesheet entry for a staff member, optionally against a job, with billing rate and notes so tracked time can feed job costs and invoicing.

Instructions

Add a timesheet entry for a staff member, optionally on a job, with billing rate and notes.

Adds one entry to Timesheets from start to end (same day, at most 24 hours) for a staff member (default the signed-in user), on a job or on none, at a billing rate (default the staff member's own) with the staff member's cost rate, as the New Timesheet Entry dialog does. Time on a job shows in its costs, the job profitability report and can be invoiced. It reaches no one.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "start": "<start>",
      "end": "<end>"
    },
    "name": "log_time"
  }
}

Input Schema

Name	Required	Description
`end`	Yes	Finish, the same day as start.
`notes`	No
`staff`	No	Staff member's full name. Default: you.
`start`	Yes	Start, ISO 8601; no zone = company time.
`job_id`	No	The job the time was spent on (list_jobs). Default: no job.
`billing_rate`	No	Billing rate name (e.g. Standard Labour Rate). Default: the staff member's own rate.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.3Oct 27, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare the write/safety profile, so the description's value is in what they cannot say: the 24-hour same-day constraint, that jobs absorb the time into costs and profitability and that it becomes invoiceable, and 'it reaches no one' meaning no notifications are sent. The downstream financial effect and the no-side-effect disclosure are exactly the kind of context annotations miss.

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 core action and its scope lead, and the second paragraph packs constraints and consequences without padding. It is slightly dense and the trailing 'It reaches no one' is terse enough to be ambiguous, but no sentence is pure filler.

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?

Given no output schema and a six-parameter mutation with full annotation coverage, the description covers the action, the day-length constraint, defaults, and downstream effects on job costing and invoicing. The only unmapped area is returned identifiers or duplicate-entry behavior, which is minor at this complexity.

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 83%, so the schema already documents five of six parameters including their defaults, and most of the description's parameter talk (staff default, billing rate default, optional job) restates it. The one real addition is that cost rate is taken from the staff member, which is not a parameter at all, so the semantic surplus is thin.

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?

It opens with a specific verb+resource ('Add a timesheet entry') and immediately scopes it ('for a staff member, optionally on a job, with billing rate and notes'), which separates it cleanly from the read-only sibling list_timesheets. An agent can pick this over the list/get siblings without opening the schema.

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?

Usage is only implied: it references 'the New Timesheet Entry dialog' as the behavioral model and names list_jobs as the way to obtain job_id, which is genuine routing help. But it never states when to prefer this over list_timesheets or what to do when time spans days or a job is not yet created, so the agent must infer the boundaries.

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