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

Annotations already declare destructiveHint=true and idempotentHint=false, so the mutation risk is covered. The description adds the valuable state constraint (unapproved and unlocked) plus ownership scope ('your own'), but says nothing about reversibility or how the caller obtains an eligible ID.

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?

Two sentences, zero filler, with the destructive action front-loaded and the eligibility constraint immediately following.

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?

For a one-parameter destructive tool with no output schema, the description covers purpose and eligibility but leaves the ID provenance and any failure behavior (what happens if the record is approved) unstated, so an agent still needs inference from sibling tools.

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 single parameter workReportId is completely unexplained in the description. With a destructive tool, telling the agent where the ID comes from (e.g. intempus_list_my_work_reports) would materially reduce mis-invocation risk, and it is absent.

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?

States a specific verb+resource ('Delete ... time registration') and explicitly scopes it to the caller's own records, which cleanly separates it from siblings like intempus_update_my_work_report and intempus_register_time.

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?

Gives a clear precondition for use ('only possible while it is neither approved nor locked'), which is real routing information. It does not name an alternative for when the record is approved/locked (e.g. correction or update), so it falls short of explicit when-not guidance.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the default date, that holiday accrues at month end (explaining why results shift), and the employee-visible scoping constraint.

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?

Three tight sentences, front-loaded with what the tool returns before the accrual tip and the visibility caveat. No filler or repetition.

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?

For a no-required-param read tool with no output schema, the description covers the concept, default, and accrual timing well. It still leaves the `from` parameter and the shape of returned balances (units, keys) entirely unaddressed.

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%, so the description carries the full burden, and it only half-delivers: it explains that `to` defaults to today and why a specific `to` matters, but the `from` parameter is never mentioned or explained anywhere.

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 names a concrete resource ('your balances (ferie, feriefri, timebank/flex, sygdom…)') and states it is computed by Intempus up to a date. No sibling tool covers balances, so it is distinguishable in practice, though it never explicitly contrasts itself with an alternative.

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?

It gives a concrete usage rule: 'pass to = the end of the holiday year to see the full entitlement,' and notes the default (today). It also scopes the audience ('Only balances visible to employees'), but offers no when-not-to-use or alternative tool guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral detail, the default 14-day window, but says nothing about return shape, volume, or timezone/scheduling semantics.

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?

A single front-loaded sentence with no filler, and the default value is placed where it is most useful. It is arguably too terse to serve its purpose, but nothing is wasted.

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 two undocumented parameters, no output schema, and no explanation of what a 'planned work' entry contains, the agent cannot know what the result represents before calling. For a query tool with zero annotation-independent documentation, this is thin.

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 coverage is 0%: neither 'from' nor 'to' has any description. The description mentions only the default window and never explains the two parameters, their format, or range inclusivity, so it fails to compensate for the coverage gap.

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?

States a specific resource ('your planned work') and scope ('in a period'), which contrasts adequately with siblings like intempus_get_my_balances and intempus_list_my_work_reports. It does not explicitly differentiate itself from those siblings, but the resource is 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?

No guidance on when to use this vs. related tools such as intempus_list_my_work_reports or intempus_register_time. The only usage-adjacent information is the default period, which is a behavior, not a usage condition.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuine value beyond that by disclosing the shape of the returned data (employee record, contracts, approver levels) in the absence of an output schema.

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?

A single front-loaded sentence with zero filler; the essential facts (owner, resource, contents) arrive immediately.

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 no parameters, no output schema, and rich annotations, the description does most of the remaining work by naming the returned sections. It could still clarify the authenticated-user scoping versus other lookups, but nothing critical is missing for a no-arg read.

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?

The tool takes zero parameters, for which the baseline is 4. The description correctly implies an implicit self-scope ("Your ... record"), reinforcing that no identifier argument is needed.

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?

States a specific resource — the caller's Intempus employee record — and enumerates its contents (contracts with work model and locked date, approver levels). However, it never distinguishes itself from the overlapping sibling intempus_whoami, which an agent could reasonably pick instead.

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?

No statement of when to call this versus siblings, and the potential overlap with intempus_whoami is left unaddressed. The agent must infer usage purely from the noun phrase.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds one real behavioral constraint (results are limited to cases accepting time registrations), but says nothing about pagination, result ordering, or the admin-only nature of includeInactive beyond what the schema states.

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?

A single front-loaded sentence with no filler; the scope constraint and searchable fields are packed efficiently. It is arguably too terse given the undocumented limit parameter, but nothing in it is wasted.

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?

There is no output schema, so the description would ideally say something about what is returned or how results are bounded. With 3 parameters, 33% schema coverage, and no return-value guidance, the definition is minimally adequate but leaves gaps an agent must guess at.

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 33%: 'query' and 'limit' are undocumented in the schema. The description partially compensates by explaining that query searches by number, name or customer, but 'limit' (max 500) is left entirely unexplained in both places. Partial compensation justifies a 3.

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?

States a specific verb (search/list) and resource (cases/projects), plus a meaningful scope qualifier: only cases that accept time registrations. It also names the searchable fields (number, name, customer). It stops short of naming any sibling tool to differentiate itself, so it lands at 4 rather than 5.

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 phrase 'cases/projects that accept time registrations' implies the workflow (find a case before calling intempus_register_time), but there is no explicit when-to-use, when-not-to-use, or comparison against siblings such as intempus_list_work_types. Usage is inferable but not stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the default period and the fact that approved status and a total are included, but says nothing about pagination behavior for the 2000-item 'limit' or ordering, which are the remaining behavioral unknowns.

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?

A single front-loaded sentence with no filler; the period scope and default come first and the returned fields follow. It is efficiently sized, though brevity comes at the cost of the parameter and behavioral detail noted elsewhere.

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?

For a read-only list tool whose annotations already cover safety and which has no output schema, this is close to adequate: scope, default, and key return fields are stated. It still stops short of documenting the filter/paging parameters, which is the main completeness gap.

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?

Four parameters with 0% schema description coverage, so the description must carry the burden. It partially covers from/to by explaining the default 31-day period, but 'limit' and 'approved' are never explained — the phrase 'with approval status' reads as a return field, not the filter, leaving the agent to guess.

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?

States a specific verb+resource: 'Your time registrations' in a period, with the included fields (approval status, total). It is distinguishable from siblings like get_my_balances or list_work_types, though it never explicitly names how it differs from get_my_planning, which also deals with the user's own time data.

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 default window ('last 31 days') tells the agent what happens if no period is supplied, which is useful invocation context. However, there is no explicit when-to-use vs. sibling guidance (e.g., vs. get_my_planning or get_my_balances) and no exclusions, so usage is only implied.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds meaningful access-scoping semantics: results are scoped to the caller's own work model unless admin, and only admins may filter by work model or employee. That visibility rule is not encoded in the annotations.

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?

Two short sentences, front-loaded with the resource and examples, then the access rule. No filler.

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?

For a parameterless-required, read-only listing tool with no output schema, the description supplies the domain examples, default scoping, and admin filter rule an agent needs. Only the free-text 'query' parameter remains unexplained.

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 coverage is 67% and both documented parameters (employeeId, workModelId) are marked admin-only in the schema. The description reinforces the admin-only filter behavior for work model and employee, but says nothing about the undocumented 'query' parameter, so it only partially compensates. Baseline 3 fits.

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?

States a specific verb and resource ('Work types') and gives concrete examples (projekttimer, ferie, sygdom, kørsel) that pin down the domain object. It does not explicitly contrast itself with siblings, but the resource is distinctive enough among the listed tools.

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 second sentence implies usage context by describing what different callers receive ('Employees and approvers get the types of their own work model'), which hints at when the tool is appropriate without stating exclusions or naming an alternative. It is implied guidance rather than explicit when/when-not routing.

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

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

Annotations already declare this is a non-read-only, open-world, non-destructive, non-idempotent write. The description adds real behavioral context beyond that: the pre-write validation rules (contract on the date, work type belonging to the work model, case being open) and the idempotencyKey mechanism to make retries safe. It does not say what happens when validation fails or what the response contains.

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?

Three tightly written sentences with zero filler; the primary action and scope come first, followed by input shape, validation behavior, and the retry tip. Every sentence carries information an agent needs.

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?

No output schema exists, but the description covers the action, required inputs, precondition checks, and idempotency behavior for an 11-parameter mutation tool. The chief remaining gap is the result/failure shape and how to recover after a validation rejection, which the description does not address.

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?

With only 45% schema coverage and 11 parameters, the description does useful compensating work: it names work type, optional case, date, startTime+endTime with optional breakHours, and hours, and clarifies the either/or rule that the schema leaves implicit. It omits meaning for remarks, additionalRemarks, and endDate (multi-day spans), so it is not fully complete.

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?

States a specific verb and resource ("Register time for yourself") that clearly identifies the write/create operation among list/get/update/delete siblings, and even scopes it to the caller. However it never names or contrasts an adjacent sibling (e.g. update_my_work_report) explicitly, so the differentiation is inferred rather than stated.

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 explains the required input combination (work type, optional case, date plus either start/end or hours) which is useful how-to guidance, but it offers no explicit when-to-use/when-not-to-use framing or alternative tool routing. Usage is implied by the operation itself rather than articulated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds only that examples are included, saying nothing about result size, ranking, or how to follow up on matches.

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?

Two short sentences with no filler: what it does first, when to use it second. Nothing could be trimmed without losing information.

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?

For a zero-required-parameter search tool with no output schema, an agent can call it correctly, but it cannot predict what comes back or how to constrain the search via query/limit. Combined with 0% param coverage, the definition is serviceable but leaves real 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 0% for both parameters, so the description carries the full burden. It never explains that 'query' is a free-text search string (e.g., empty returns everything) or that 'limit' caps results with a default of 20 and a max of 50, leaving both params undocumented.

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?

States a specific verb (search) and resource (Intempus MCP server capabilities and examples), and its meta/discovery nature clearly distinguishes it from the ten sibling work-report/account tools. 'Capabilities and examples' is slightly abstract, but the intent is 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?

'Use this first when deciding which tool to call' gives an explicit, actionable usage condition that no sibling would satisfy. It doesn't enumerate exclusions or post-discovery behavior, but for a discovery entry-point that is acceptable.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description usefully adds that the result is tied to the current session binding and includes approver levels, but says nothing about auth requirements, error behavior when unauthenticated, or response shape.

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?

A single compact sentence that is front-loaded with the verb 'Show' and the payload. The only waste is the slightly confusing 'this endpoint's profile' construction, which costs a word of clarity rather than length.

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?

For a zero-parameter read-only tool there is no output schema, so the description carries the burden of describing what comes back; it lists profile, employee and approver levels, which is a reasonable sketch but not complete (no mention of structure, IDs, or what the 'endpoint profile' contains).

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?

There are zero parameters and 100% schema description coverage, so the baseline is 4. The description adds nothing about parameters because there is nothing to add.

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 names a recognizable resource (the session's profile / bound Intempus employee and approver levels), but the phrasing 'this endpoint's profile' is odd and it never distinguishes itself from the sibling intempus_get_my_profile, which appears to retrieve overlapping identity information.

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?

No when-to-use guidance and no exclusions are given. With intempus_get_my_profile in the sibling list, the agent is left to guess which identity tool to call; the description should say why you would call whoami instead of get_my_profile.

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