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

Annotations already declare readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the write/network profile is known. The description adds useful domain semantics, mapping child=true to absence type 5 vs type 4 and explaining the sick-note flag, but says nothing about required permissions, behavior on overlapping existing absences, or what happens when a range spans weekends/holidays.

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?

One front-loaded summary sentence followed by a compact Args list; every line earns its place. Slight redundancy between the summary and the child parameter note, but no real waste.

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 mutation tool with no output schema and four parameters, the description covers inputs well but omits failure modes, permission requirements, and whether booking a range creates one entry or many. It is adequate but leaves real gaps an agent would want filled before invoking.

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%, so the description carries the full burden and largely succeeds: it documents all four parameters, specifies the YYYY-MM-DD date format, and clarifies that sick_note means a doctor's certificate exists. Only the default-value behavior (both booleans default false) is left to the schema.

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 ('Report') and resource ('sick day') scoped to the authenticated user, with the range variant noted parenthetically. It is clearly distinguishable from add_my_vacation by resource, though it does not explicitly name that sibling as the 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?

The description gives no when-to-use guidance, no prerequisites, and no comparison against alternatives such as add_my_vacation or edit_my_time_entry. The agent must infer from the resource name alone that this is the correct tool for recording sickness absences.

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 the safety profile (readOnly=false, idempotent=false, destructive=false, openWorld=true). The description adds genuinely useful behavior beyond that: timezone semantics for time_since/time_until (local Europe/Zurich or any ISO 8601 with offset, normalized to UTC), which is non-obvious and not derivable from the 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?

Front-loaded one-line purpose followed by a parameter list; every line earns its place given the 0% schema coverage. The Args block restates parameter names but adds the missing semantics, so it is not wasted space.

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 7-param mutation with no output schema, the description covers inputs and timezone handling but omits what is returned (created entry ID), validation/error behavior for bad customer or service IDs, and any auth/permission prerequisites beyond 'authenticated user'.

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 must carry parameter meaning and largely does: all 7 params are explained, including defaults (billable=1/0, projects_id and text optional) and the critical datetime format with example. It could be stronger on confirming integer types for the *_id fields, but it compensates well for the zero coverage.

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 ('Add a manual time entry') and scopes it to the authenticated user. The word 'manual' implicitly separates it from start_my_clock/stop_my_clock, but the description never names those siblings, so differentiation is left to inference.

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?

Usage is only implied: 'manual time entry' suggests this is for retroactive/logged entries rather than live timer control, but the description gives no explicit when-to-use, when-not-to-use, or pointer to start_my_clock, edit_my_time_entry, or delete_my_time_entry.

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 disclose the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true). The description adds a genuine behavioral constraint not present in structured data: half_day is only accepted by Clockodo for a single day, requiring date_since == date_until. It omits any mention of permissions or failure behavior.

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?

Front-loaded with the one-line purpose followed by a compact Args block. Every line earns its place and there is no filler; the formatting is slightly schema-like but efficient.

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 simple three-parameter mutation with annotations covering the safety/idempotency profile, the description covers purpose, all parameters, formats, and the key half-day edge case. No output schema exists, so nothing about return values is owed, though failure/permission behavior is 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 must compensate, and it does: it documents all three parameters and supplies the YYYY-MM-DD format for both dates as well as the half_day cross-field constraint. It does not mention the false default for half_day, but this is a solid effort given zero schema coverage.

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 ('Add') and resource ('a vacation') scoped to the authenticated user, which is immediately distinguishable from edit_my_vacation, delete_my_vacation, and add_my_sick_day. It does not explicitly name or contrast those siblings, so a 4 rather than a 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 description says nothing about when to use this tool versus edit_my_vacation or add_my_sick_day, nor any prerequisites. The half_day note is a domain constraint, not usage 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 destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the agent's safety profile is covered. The description adds only the 'authenticated user' scoping constraint and nothing about permanence, re-auth, or deletion side effects, so its added value is modest.

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 lines with the verb and scope front-loaded, followed by a compact Args block. Nothing is wasted, though the Args restatement is thin enough to be near-redundant.

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 mutation tool whose annotations cover destructiveness and idempotency, the description plus schema are sufficient to call it correctly. Missing details about reversibility are largely covered by destructiveHint.

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 must carry entry_id's meaning; it does say entry_id is the ID of the entry to delete, which is minimal but real compensation. It adds no format, ownership, or lookup guidance for the ID.

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 ('Delete a time entry') and scopes it to the authenticated user, which reasonably separates it from the vacation/absence siblings. It does not explicitly name a sibling tool, so it stops short of the top score.

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 use this versus edit_my_time_entry, delete_my_vacation, or other time-entry operations, and no preconditions beyond the implicit 'you must own the entry'. Usage is only inferable from the tool name.

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 destructive=true and idempotent=true, so the safety profile is covered, yet the description adds a genuinely non-obvious behavioral rule: approved absences are withdrawn first because Clockodo refuses direct deletion. That is exactly the kind of side-effect disclosure an agent needs before calling a destructive 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 core sentence and the withdrawal caveat are front-loaded with no wasted words, but the trailing "Args:" block largely repeats the one-parameter schema and adds little beyond the tautological label.

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 single-parameter destructive tool with full annotation coverage and no output schema, the description supplies the one thing an agent could not infer (approved-absence withdrawal). It could still mention error behavior or how to obtain a valid absence_id, but nothing critical is missing.

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 must carry the parameter burden, and it only offers "ID of the absence to delete" — essentially a restatement of the name and type. It tells the agent nothing about where the ID comes from (e.g. get_my_absences) or format expectations.

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 a vacation/absence") and scopes it to "the authenticated user," which cleanly separates it from add_my_vacation, edit_my_vacation, and delete_my_time_entry without needing to open a schema.

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?

Usage is implied by the verb and the "my_vacation" naming, but the description never states when to prefer this over edit_my_vacation (e.g. cancelling vs. modifying) or any preconditions/exclusions. Adequate but with a clear gap.

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 declare the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true), and the description adds substantive context beyond them: partial-update semantics and the timezone contract that local Europe/Zurich times or ISO 8601 with offset are converted to UTC before being sent. It still does not say what gets destroyed or what happens when editing an already-billed entry, so it is not exhaustive.

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?

Front-loaded with purpose and the partial-update rule, then a compact Args list that earns its space by adding semantics the schema lacks. Slightly list-heavy, but no sentence is 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 an 8-parameter mutation tool with 0% schema coverage, no output schema, and a destructive hint, the description covers the parameters and the timezone behavior well. Remaining gaps are secondary: failure behavior, permission requirements, and any restrictions on editing billed or locked entries.

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 does so: every one of the 8 parameters is documented, including the non-obvious billable codes (0/1/2 = not billable/billable/already billed) and the accepted time formats for time_since/time_until. The format and unit details go well beyond the bare schema types.

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 ('Edit one of your time entries') and immediately clarifies the partial-update semantics ('Only the fields you pass are changed'). It does not explicitly name sibling alternatives like delete_my_time_entry, but the add/edit/delete distinction is unambiguous from the name and opening sentence.

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 real precondition ('Pass at least one field'), which prevents the common mistake of calling a no-op edit. However, it offers no when-to-use guidance relative to siblings (e.g., delete_my_time_entry for removal, or when to prefer add_my_time_entry), 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 flag destructive, idempotent, open-world mutation, so the bar is lower. The description adds genuinely useful behavior beyond them: partial-update semantics ('Only the fields you pass are changed') and the domain constraint that a half-day absence must cover a single day. It doesn't mention permission requirements or failure modes.

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?

Front-loaded with the core action, then the id source, then the edge-case workflow. The half-day paragraph is longer than the rest but earns its place by preventing an invalid booking; the Args block is a slight duplication of what could be inline.

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 destructive, open-world mutation with no output schema, the description covers partial-update behavior, id provenance, and the key validation rule. Missing only secondary details such as overlap/conflict handling and what the tool returns or how it reports failure.

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 must carry the load, and it does: all four params are documented with meaning and format (YYYY-MM-DD dates, boolean half-day, id provenance from get_my_absences). The 'only fields you pass are changed' line implicitly explains the nullable defaults, though it never states defaults explicitly.

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 ('Change the dates or half-day flag of one of your absences') and scopes it to the caller's own records. An agent can immediately distinguish it from add_my_vacation, delete_my_vacation, and edit_my_time_entry.

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?

Points to get_my_absences as the source of absence ids and explains the alternative route for mixed full/half-day bookings (shorten here, then add_my_vacation(..., half_day=True)). It stops short of stating when to prefer edit over delete/re-create, so it is clear context rather than full when/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 cover the read-only/open-world profile, and the description goes beyond them by enumerating the return fields and flagging that returned text is user-provided data rather than instructions (a useful prompt-injection caveat). It offers no pagination, rate-limit, or volume information, but for a straightforward read this is solid context.

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?

Front-loaded with purpose, then return fields, then arg semantics. Every sentence adds necessary information; there is no filler or restatement of the tool name.

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 output schema, the description supplies the return shape (id, date_since, date_until, type, status, count_days), the safety caveat, and complete arg semantics. Nothing an agent needs to select or invoke this tool correctly is missing.

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%, so the description must carry the load and does: 'year' is defined as the calendar year to list, and 'absence_type' is fully decoded with the five Clockodo code values, information absent from the schema. No ambiguity remains about how to call it.

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 plus scope ('authenticated user's absences for a year, all statuses'), which cleanly separates it from sibling mutations like add_my_vacation and delete_my_vacation. The added note that the returned id is what delete/adjust operations require further pins its role in the workflow.

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?

Filtering behavior is explicit: absence_type narrows results and 'when omitted, all types are returned.' It also implies the read-then-mutate workflow by noting the id is needed to delete or adjust. It does not, however, name a sibling alternative or state when-not to use it, so it stops short of a 5.

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 and openWorldHint=true, so the safety profile is partly covered. The description adds valuable context that returned text fields are user-provided data and not instructions, which is an important prompt-injection caveat. It does not describe return format or empty-clock behavior, but it adds meaningful behavioral disclosure beyond 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 purpose and then a security caveat. Nothing is wasted or redundant with the title, schema, or annotations.

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 simple read-only tool with no parameters and no output schema, the description is largely complete: it states the purpose and warns about user-provided returned text. It could be slightly more complete by noting what happens when no clock is running, but it is adequate 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?

The tool takes zero parameters, so the baseline is 4. The input schema is an empty object and schema coverage is 100%, so no additional parameter semantics are needed or expected.

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 ('Get') and resource ('currently running clock') scoped to the authenticated user. The purpose is clear, but it does not explicitly distinguish this tool from siblings such as get_my_time_entries or start_my_clock/stop_my_clock.

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 or when-not-to-use guidance is provided, and no alternatives are mentioned. The agent must infer from the name that this is for checking an active clock rather than listing time entries or starting/stopping the clock.

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 and openWorldHint=true, so the safety profile is covered. The description adds genuine context beyond that: input times are interpreted as Europe/Zurich local or ISO 8601 with offset and converted to UTC for Clockodo, and returned description fields are untrusted user data rather than instructions — a useful prompt-injection warning. It does not mention pagination or result limits.

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 purpose sentence is front-loaded, followed by the security note and then the args. The content is dense but each part earns its place; the docstring-style 'Args:' block is slightly formal but not wasteful.

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 output schema, the description still discloses that entry descriptions are returned as untrusted text, and the annotation pair covers read-only/open-world behavior. For a simple two-parameter read tool this is close to complete, though result shape and paging remain unspecified.

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 does so well: both required params are explained with timezone semantics (local Europe/Zurich or ISO 8601 with offset), the UTC conversion behavior, and concrete example values. This is meaningfully richer than the bare 'Time Since'/'Time Until' schema titles.

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 ('Get time entries') and scopes it to the authenticated user and a time range, which cleanly separates it from write siblings like add_my_time_entry or edit_my_time_entry. It does not explicitly name a sibling alternative (e.g. get_my_clock), so it stops short of full differentiation.

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?

There is no statement of when to use this tool versus get_my_clock, get_my_absences, or the edit/delete variants. The only conditional content is parameter documentation, not usage guidance, so an agent must infer the correct tool from the name alone.

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 and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond restating that this is a server-level check — no mention of what a healthy vs unhealthy result looks like or any auth/pagination considerations.

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 short sentence, front-loaded with the verb and resource. Nothing extraneous.

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?

An output schema exists, so return values need not be described. For a zero-param liveness check with annotations covering the safety profile, the definition is essentially complete; only a hint about interpreting the result would improve it.

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, so per the rubric the baseline is 4. There is no parameter meaning for the description to add or omit.

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: a health check scoped to the Clockodo MCP server. It is unambiguously distinct from all sibling tools, which are data operations, though it does not explicitly name that contrast.

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?

Usage is implied (verify server availability/liveness) but never stated. There are no alternatives to weigh here, so the lack of explicit when-to-use guidance is a minor gap rather than a misleading one.

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 and openWorldHint=true, so safety and external-call nature are covered. The description adds nothing beyond that – no mention of pagination, rate limits, result size, or authentication requirements.

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?

One short, front-loaded sentence with no filler. It is efficient, though it borders on being too terse to be informative.

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 trivial zero-parameter read tool this is close to sufficient, but with no output schema the description could still say whether all customers are returned at once or paginated. Annotations cover the safety profile, so the remaining gap is minor but real.

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, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond what the empty schema already conveys.

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 clear verb+resource ('List all customers'), so the agent knows exactly what the tool returns. It does not, however, distinguish itself from siblings like list_projects or list_services, which follow an identical naming pattern.

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?

There is no guidance on when to use this tool versus the other listing siblings, nor any prerequisites or context about the Clockodo domain. The agent must infer usage from the name alone.

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 and openWorldHint=true, so the safety and external-dependency profile is covered. The description's 'List all' adds the useful detail that no filtering or pagination is applied, but it says nothing about result shape or size — adequate but not rich.

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 short sentence with no filler, and the resource is front-loaded after the verb. It is perhaps over-terse but wastes no words.

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 list tool with no output schema, the definition is minimally complete: annotations cover the read-only nature. However it omits anything about return format, result volume, or ordering, which an agent calling an unfiltered 'all projects' endpoint might want to know.

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, so the schema carries no semantics for the description to supplement. The baseline of 4 applies for a parameterless definition.

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?

Names a specific verb ('List') and resource ('projects') plus the source system (Clockodo API), so the agent knows exactly what it returns. It does not differentiate from the similar sibling listers (list_customers, list_services), but the resource itself 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?

There is no guidance on when to choose this over list_services, list_customers, or any other listing sibling, and no prerequisites or exclusions are stated. Usage is only implied by the verb.

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 and openWorldHint=true, so the safety and external-API profile is covered. The description adds only 'from Clockodo API,' which is redundant with openWorldHint and does not disclose pagination, rate limits, or what 'all' entails.

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 a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple, zero-parameter list operation.

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 list tool with annotations covering safety and open-world access, the description is nearly complete. It could mention pagination or the scope of 'all services,' but no output schema exists and the core purpose is clear.

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 has zero parameters, and the schema coverage is 100% (vacuously). Per the rubric, a zero-parameter tool receives a baseline of 4, and the description offers no parameter details to add or detract.

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 ('List') and resource ('services'), making the tool's function immediately clear. It does not explicitly differentiate itself from sibling list tools like list_projects or list_customers, but the resource name does imply a distinct target.

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 provides no guidance on when to use this tool versus alternatives such as list_projects or list_customers, nor any prerequisites or exclusions. It simply states what the tool does without context for selection.

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, openWorldHint=true and destructiveHint=false, so the mutation/non-idempotent profile is covered. The description adds only the 'authenticated user' scoping (the clock belongs to the caller, not an arbitrary user), but says nothing about what happens if a clock is already running or what the call returns.

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?

One front-loaded purpose sentence followed by a compact args list; no filler or redundant prose. The args block repeats parameter names from the schema, but each line still adds a small amount of semantics.

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 mutation tool with no output schema, the definition covers the essentials (purpose, scope, all params) and annotations carry the safety profile. It leaves gaps around preconditions (existing running clock) and failure behavior, which an agent starting a timer would plausibly need.

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 largely meets it: it documents all five parameters and adds the non-obvious encoding 'billable (1) or not (0)', which the bare integer schema does not convey. The remaining parameter notes are terse and mostly restate the names.

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 opening sentence states a specific verb and resource ('Start the clock') and scopes it to the authenticated user, which clearly separates it from sibling stop_my_clock and get_my_clock by name. It stops short of explicitly naming the alternative tools or contrasting with them, so it earns a 4 rather than a 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 description gives no when-to-use guidance, no prerequisites, and never mentions the sibling stop_my_clock or get_my_clock that an agent would choose between. The only signal is the tool name itself, which is implied rather than 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 the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so safety is covered structurally. The description adds only that the operation is scoped to the authenticated user; it does not explain behavior when no clock is running or what the idempotent no-op case looks like, so it adds modest value beyond 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?

A single front-loaded sentence with no filler. Every word earns its place and the target scope is stated 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?

For a zero-param mutation, the safety profile is carried by annotations and no output schema exists, so little is missing. Still, the description omits the no-clock-running case and any confirmation of what state results, leaving a small but real gap for an agent deciding whether the call is safe to issue.

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, so there is nothing for the description to clarify; baseline 4 applies. The description correctly reinforces that the target is implicit (authenticated user's running clock).

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 (stop) and resource (clock) scoped to the authenticated user, and 'currently running' implies it targets an active timer rather than an arbitrary one. It is distinguishable from start_my_clock and get_my_clock, though it never names them explicitly.

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 'currently running' implies the prerequisite that a clock must be active, which is useful implied usage guidance. However, there is no explicit when-to-use statement, no mention of what to do if no clock is running, and no routing guidance against the sibling start_my_clock.

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