Skip to main content
Glama
borgels

MCP Server for Visma Intempus

by borgels

Edit My Time Registration (Intempus)

intempus_update_my_work_report

Update one of your own time registrations when it is neither approved nor locked. Change hours, dates, case, work type, or remarks for an existing work report.

Instructions

Change one of your own time registrations. Only possible while it is neither approved nor locked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoWork date (start date).
hoursNoAmount in the work type unit (hours for time). Derived from start/end minus break when omitted.
caseIdNoCase/project id from intempus_list_cases. Omit for time without a case (e.g. absence).
endDateNoOnly for registrations spanning several days (e.g. holiday).
endTimeNo
remarksNo
startTimeNo
breakHoursNo
workTypeIdNoWork type id from intempus_list_work_types.
workReportIdYes
additionalRemarksNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the mutation profile is partly covered. The description adds real value with the approved/locked state precondition. However, for an 11-parameter update it omits critical behavior: whether omitted fields are preserved or cleared (partial vs full replace) and what happens on a rejected edit.

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?

Two compact sentences with the action stated first and the constraint second; every clause carries information and nothing is padded.

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

Completeness3/5

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

For a low-coverage, 11-parameter mutation with no output schema, the description covers purpose and one eligibility rule but leaves partial-update semantics, required-field guidance, and permission requirements unaddressed. Adequate as a minimum viable description, but not complete for the tool's complexity.

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

Parameters2/5

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

Schema description coverage is only 45% across 11 parameters, so the description was expected to compensate and does not. It names no parameter, no required field (workReportId), and no interaction rules such as hours being derived from startTime/endTime/breakHours when omitted.

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?

States a specific verb and resource with explicit ownership scope: 'Change one of your own time registrations.' This cleanly separates it from intempus_register_time (create) and intempus_delete_my_work_report (delete). It stops short of naming any sibling directly, so it is clear but not fully differentiated in-text.

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

Usage Guidelines4/5

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

Provides a concrete when-not condition: 'Only possible while it is neither approved nor locked,' which tells the agent when the call will fail. It does not, however, point to an alternative (e.g. register_time for new entries) or mention prerequisite lookups from list_cases/list_work_types that the id parameters imply.

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