ExakTime / Arcoro MCP by usefulapi

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

Annotations already cover the write/non-destructive/non-idempotent profile, so the description's added value is the uniqueness constraint (a server-side rejection condition) and the no-delete lifecycle fact, plus the REST endpoint. It stops short of saying what error/duplicate behaviour or permissions look like, but it meaningfully exceeds what annotations declare.

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 short sentences with zero filler; the 'WRITE:' prefix front-loads the mutation nature, then purpose, then constraint, then lifecycle alternative.

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?

Covers mutation intent, uniqueness, and the no-delete follow-up path, which is what an agent needs to avoid a failed call. Minor gap: no output schema exists and the description does not indicate what is returned (e.g., new cost code id) for subsequent calls.

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 100%, including the uniqueness note on 'name' and the display_option enum semantics, so the schema carries the parameter burden. The description adds essentially nothing parameter-specific beyond repeating uniqueness, which matches the baseline 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 and resource ('create a cost code') and immediately clarifies the domain concept ('phase or work activity that time can be booked against'). It also distinguishes itself from get/list/update siblings by naming the lifecycle tool (exaktime_update_cost_code) 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?

Gives the essential precondition (name must be unique) and the lifecycle rule that deactivation is done via exaktime_update_cost_code because there is no delete. It does not explicitly contrast with list/get siblings, but for a create tool the when-to-use is effectively implied by the unique-name and no-delete 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 cover the write/safety profile, and the description contributes beyond them: the job appears in Arcoro immediately, identifiers are uniqueness-constrained, and the resource has no delete path. Missing is any note on auth/rate limits or error behavior on duplicate identifiers.

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 the WRITE marker and the action, then the key constraint, then the lifecycle alternative and endpoint. 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 create endpoint with no output schema, the description never says what comes back (e.g., the new job's id) – something an agent needs to chain into exaktime_update_job or sub-job creation. Everything else an agent needs is present in the schema and annotations.

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 100%, so the schema already documents all ten fields including the identifier uniqueness and the location_ids/all_locations interaction. The description's only parameter-adjacent content ('identifier must be unique') restates the schema, so baseline 3 applies.

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 the specific verb ('create') and resource ('a job (project)'), plus the underlying endpoint POST /v1/Time/Jobs. The parenthetical clarifies what a job is and its role in time booking, which cleanly separates it from sibling readers like exaktime_list_jobs and exaktime_get_job.

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?

Adds real routing guidance: the identifier must be unique, and there is no delete – deactivation goes through exaktime_update_job. It does not state what to do when a duplicate identifier already exists (get/update instead), which keeps it 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 state readOnlyHint=false, idempotentHint=false and destructiveHint=false; the description adds real context beyond that: it is a POST to /v1/Common/Locations, there is no delete operation, and address/lat-long drive geofencing and maps. What is missing is how the created record is returned (no output schema) and whether duplicate names are rejected.

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 short sentences with the WRITE marker and the resource front-loaded, followed by the practical tip and the lifecycle caveat. Every sentence carries distinct information with no repetition of the title or schema.

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 10-parameter mutation with a nested address object and no output schema, it covers the essential behavioral facts an agent needs to call it and to know the record cannot be deleted. The remaining gap is the return value (presumably the new location id), which matters since there is no output schema to describe 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?

Schema coverage is 60%, so the schema already documents several fields; the description adds the useful hint that address and latitude/longitude are optional inputs that make geofencing and maps work. It says nothing about identifier, is_office, is_time_and_attendance, or onboarding_business_unit_id, so it does not fully 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?

Opens with an explicit verb+resource ('create a location (job site or office)') and adds the scope clarification that it covers both job sites and offices. It also names the sibling exaktime_update_location, so the agent can distinguish creation from modification/lifecycle management without opening another 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?

Gives the important lifecycle rule that deactivation goes through exaktime_update_location because there is no delete, which prevents an agent from hunting for a delete tool. It does not cover prerequisites (permissions, whether the location name must be unique), but the create-vs-update routing is explicit.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description's only added value is the concrete endpoint path GET /v1/Time/CostCodes/{id}, which is mildly useful for troubleshooting but adds no behavioral detail such as error behavior on missing ids.

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 fragments, front-loaded with the outcome and followed by the backing endpoint; nothing extraneous. It is arguably too terse to be maximally useful, but no sentence 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?

For a single-record read with one well-documented parameter and annotation coverage, most of the contract is present. The notable gap is that no output schema exists, yet the description says nothing about what a cost code record contains or how a not-found case behaves.

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 is a single parameter and schema description coverage is 100% ('Arcoro cost code id.'), so the schema fully carries parameter meaning. The description repeats the concept of an id but adds no format, range, or sourcing guidance beyond 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-and-resource pair ('One cost code by id') plus the underlying endpoint, which lets an agent distinguish it from exaktime_list_cost_codes at a glance. It stops short of explicitly naming that sibling, but the singular 'one' vs. list distinction is conveyed.

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?

'One cost code by id' implies retrieval of a single known record, which implicitly differentiates it from the list and create siblings. However, there is no explicit when-to-use statement, no mention of prerequisites, and no guidance on what to do if the id is unknown.

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds the underlying endpoint (GET /v1/Common/Persons/{personId}/Employees) and, critically, enumerates the payload contents in the absence of an output schema — real added value. It omits edge behavior such as what happens when a person has no employee record.

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: the return-field inventory is front-loaded, then the endpoint. The long field list earns its place because no output schema exists, and there is no filler prose.

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 read tool with annotations covering safety, the description supplies the return shape that the missing output schema would otherwise provide. The remaining gap — behavior when the person has no employment record — is minor but worth noting.

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?

Only one parameter, person_id, and the schema documents it at 100% coverage ("Arcoro personId.", integer, >0). The description adds nothing about the identifier beyond what the schema already says, so the baseline 3 applies.

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 (employment details for a person) and enumerates the concrete fields returned — hire/termination date, status, pay type, pay rates, job code, manager, location, department, pay schedule, union. This clearly separates it from exaktime_get_person (personal data) and exaktime_list_employees (roster), though it never names those siblings 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?

Usage is only implied: you need a person_id, so you must already have a person from get_person or list_persons. No explicit when-to-use/when-not or statement about preferring list_employees for multiple people is given, so the agent must infer the retrieval chain.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the concrete GET endpoint, but does not disclose anything further about authentication, missing-record behavior, or response characteristics; for a simple read this is 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?

The description is two short fragments with no wasted text, and the core action is front-loaded before the endpoint. For a single-parameter read tool, this is appropriately sized.

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?

Given the low complexity, complete parameter schema coverage, and annotations covering read-only behavior, the definition provides enough for correct invocation. It is slightly incomplete in not indicating what the job response includes, but no output schema exists and the operation is straightforward.

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 100%, and job_id is documented as 'Arcoro jobId' with integer constraints in the schema. The description only adds that lookup is by id, which does not meaningfully extend the schema's parameter semantics.

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 retrieval action and resource: 'One job by id,' reinforced by the HTTP path 'GET /v1/Time/Jobs/{id}.' It clearly distinguishes a single-job lookup from list-oriented siblings like exaktime_list_jobs, though it does not explicitly name alternatives.

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 'by id' implies the tool should be used when a single job identifier is known, but there is no explicit guidance on when to use this versus exaktime_list_jobs or exaktime_query_odata. Usage is inferable 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 readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the REST endpoint path, with no note on auth requirements, not-found behavior, 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?

Two short fragments, zero filler, front-loaded with the resource and scope. Slightly telegraphic rather than prose, but nothing 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?

For a one-parameter read tool with full annotation coverage and no output schema, most of what an agent needs is present. It still doesn't say what a successful response contains or what happens on an invalid id, leaving a modest 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?

Schema coverage is 100% and the single location_id parameter is documented as an Arcoro locationId with constraints. The description's 'by id' adds no format or semantics beyond what the schema already provides, so the baseline 3 applies.

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 (location) and a scoping verb (one by id), plus the underlying endpoint GET /v1/Common/Locations/{id}. Singular-by-id wording implicitly separates it from exaktime_list_locations, but no sibling is named 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 'One location by id' implies use it when a single known location is needed rather than a list, but there is no explicit when/when-not statement or named alternative such as exaktime_list_locations.

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, destructiveHint=false, so the safety profile is covered. The description adds genuine value by disclosing the field set returned and the scope limitation that government identifiers are unavailable through this server, but says nothing about not-found behavior or permissions.

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 plus an endpoint reference, with the returned-field information front-loaded. The endpoint path is marginally redundant with the schema but earns its place as an API mapping hint.

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 usefully enumerates the returned fields and flags the government-identifier exclusion, which is exactly the kind of scope detail an agent needs. The main missing piece is disambiguation from get_employee/list_persons.

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 100% and the sole parameter person_id already carries a description ('Arcoro personId'). The description only echoes the path template GET /v1/Common/Persons/{personId}, adding no new meaning such as format or source of 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 resource (one Person record) and enumerates the returned fields (names, contact details, address, login username, security groups), which distinguishes it from the list_* siblings. However, it never clarifies how a 'Person' differs from an 'employee' despite exaktime_get_employee being a direct sibling, leaving a real ambiguity.

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 explicit statement of when to use this tool versus exaktime_list_persons or exaktime_get_employee; the single-record nature is only implied by 'One Person record'. No prerequisites or exclusion conditions are given.

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 destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the shape of each returned record (identifier, name, active flag, cost type) and the semantic definition of a cost code, which matters since there is no output schema. It omits response envelope details such as total counts and next_page.

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: the parenthetical definition comes first, the field list second, and the endpoint is appended. Nothing repeats the title or wastes a clause.

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, zero-required-parameter list endpoint with fully annotated params and read-only annotations, the description covers purpose, domain meaning, and returned fields. The one gap is the response envelope (paging metadata, totals), which the agent will only discover at call time.

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 100% and both parameters (page, page_size) carry their own ranges, defaults, and the useful 'pass the previous reply's next_page' instruction. The description adds nothing about pagination, so baseline 3 applies.

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?

Specific verb+resource (list cost codes) plus a clarifying gloss that these are 'phases and work activities that time is booked against', which grounds the domain term. It also enumerates the returned fields and names the endpoint. It doesn't explicitly contrast with exaktime_get_cost_code, 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?

Usage is only implied: an agent can infer this is the bulk-enumeration path and get_cost_code is the single-record path, but the description never says so. There is no statement of when to prefer this over exaktime_query_odata or how to iterate pages, leaving the agent to infer behavior.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by naming the returned fields (identifier, name, active flag) and the backing endpoint, but says nothing about pagination, result volume, or filtering behavior beyond what the schema already shows.

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 tight sentence plus the endpoint reference; the resource definition is front-loaded where it matters. Nothing is wasted, though the endpoint string is arguably redundant with 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?

For a simple read-only list tool with two fully documented pagination params and no output schema, the description covers what the resource is and what fields come back. Pagination semantics live in the schema, so the remaining gap is minor.

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?

Both parameters (page, page_size) have 100% schema description coverage including defaults and the 'pass the previous reply's next_page' hint, so the description need not compensate. It adds no parameter meaning of its own, making the baseline 3 appropriate.

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?

Specific verb+resource ('List cost types') with a parenthetical that defines the concept as 'groupings of cost codes, e.g. labor, equipment', which effectively separates it from the sibling exaktime_list_cost_codes. It stops short of explicitly naming that sibling, but the relationship 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?

The description gives no when-to-use guidance, no exclusions, and no pointer to alternatives such as exaktime_list_cost_codes or exaktime_query_odata. The agent must infer that this is the lookup to use before creating or updating cost codes.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint (GET /v1/Common/Departments) and the field set returned, which is useful context since there is no output schema, but it says nothing about pagination behavior or result volume.

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 terse sentences with no filler: the resource and returned fields come first, followed by the underlying endpoint. Nothing is wasted or repeated from structured fields other than a brief echo of the title.

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?

This is a simple two-parameter read tool with full schema coverage and clear annotations. The description supplies the returned field set (valuable since there is no output schema) and the endpoint, though pagination semantics, already in the schema, are not summarized.

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 100%, and both parameters (page, page_size) are documented in the schema including defaults and the next_page chaining hint, so the description needn't compensate. It mentions neither parameter, which is fine at full coverage, keeping this at the baseline.

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 ('List departments') and even enumerates the fields returned (identifier, name, active flag). It does not explicitly differentiate from the many sibling list_* tools, but the resource name makes intent 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?

Usage is only implied by the generic 'list' verb; there is no explicit statement of when to call this instead of exaktime_get_* style lookups or exaktime_query_odata. For a simple read-only enumeration tool this is acceptable but leaves the agent to infer the boundary.

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, openWorldHint=true, and destructiveHint=false. The description adds useful context by specifying the employee-type scope, the returned fields, and the underlying GET endpoint, though it does not mention pagination or result ordering.

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 tight sentences with no wasted words. The core purpose and returned fields are front-loaded, followed by the relevant detail-lookup guidance.

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 appropriately enumerates the returned fields and states the employee-type scope. Pagination is handled by the schema, and the description provides enough for correct invocation, though it could note whether inactive employees are included by default.

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 100%, and both page and page_size are fully documented in the schema. The description adds no additional meaning about these parameters, so the baseline score of 3 applies.

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 gives a specific verb ('List') and resource ('employees'), clarifies these are Person records of type Employee, and enumerates the fields returned. This distinguishes it from exaktime_list_persons, which presumably covers all persons rather than only employees.

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 explicitly points to exaktime_get_employee for retrieving details using personId, giving clear follow-up guidance. It does not explicitly state when to choose this over exaktime_list_persons, so it stops short of 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds the underlying endpoint (GET /v1/Common/JobCodes) and enumerates the returned fields, which is modest but real added context; it says nothing about pagination limits, ordering, or whether results include inactive codes by default.

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 tight sentences with the core purpose front-loaded and no wasted prose. The raw endpoint path is mildly technical filler for an agent but does add traceability, so it just misses a 5.

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 list tool with no output schema, the description compensates by naming the returned fields (name, description, active flag), and annotations plus a fully documented schema cover safety and paging. The main remaining gap is the unresolved overlap with exaktime_list_jobs.

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 100%, with page and page_size fully documented (ranges, defaults, and the 'pass the previous reply's next_page' guidance). The description adds nothing about parameters, which is acceptable given the schema does all the work, but it means no credit above baseline.

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 ('List job codes') and clarifies the domain term by equating job codes with positions/trades, which helps an agent that might not know ExakTime terminology. It does not, however, distinguish this from the sibling exaktime_list_jobs, so the job-code-vs-job boundary is left implicit.

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 given, and no alternative is named even though exaktime_list_jobs, exaktime_list_cost_codes, and exaktime_query_odata are plausible routes to overlapping data. The agent must infer applicability purely from the 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context by naming the underlying endpoint (GET /v1/Time/Jobs) and the fields returned, but says nothing about pagination behavior or rate limits beyond what the schema covers.

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 dense sentence with the purpose front-loaded followed by the returned-field list and endpoint. No filler, though the raw endpoint path is marginal value for an agent.

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, and the description compensates by enumerating the returned fields (identifier, name, active flag, dates, department, parent job, locations), so an agent knows what to expect. With only two well-documented params and annotations covering safety, the definition is nearly complete; only pagination return shape is left implicit.

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 100% for both parameters (page and page_size, with defaults, ranges, and the next_page chaining hint). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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, clarifies that 'jobs' means projects, and enumerates the returned fields, which lets an agent distinguish it from the mutation siblings (create_job, update_job). It never names exaktime_get_job as the single-record alternative, so differentiation is implied rather than explicit.

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 verb 'List' implies a retrieval context, but there is no statement of when to prefer this over exaktime_get_job for a single job or exaktime_list_locations for location data. No prerequisites or filtering guidance are given, leaving usage to inference.

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, destructiveHint=false, and openWorldHint=true, and the description is consistent with them by showing a GET endpoint. It adds the returned field list, but does not elaborate on pagination behavior, auth needs, or rate limits beyond what the schema already implies.

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 the operation and returned fields front-loaded, plus the endpoint path. There is 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 simple read-only list endpoint, the description covers purpose, returned fields, and the underlying API path; annotations cover the safety profile and the schema documents pagination. It could mention the pagination response shape more explicitly, but no critical information 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 100%, and both page and page_size are described directly in the schema, including the use of next_page. The tool description does not add parameter-specific semantics, so baseline 3 is appropriate.

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 gives a specific verb and resource ('List labor classes') plus the returned fields (identifier, name, active flag), making the operation unmistakable. Against a large set of sibling list_* tools, the resource name alone distinguishes it cleanly.

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 listing intent is implied by 'List labor classes', and the tool is resource-specific enough that selection is fairly obvious. However, it does not explicitly say when to use it versus related tools like exaktime_query_odata or any get_* variant, nor does it state exclusions or prerequisites.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value by disclosing the shape of the returned record (address, coordinates, active flag, attendance usage), which matters since there is no output schema. It says nothing about pagination behavior or result volume, which the schema only partially covers.

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 names the resource, its subtypes, and the payload fields, with the endpoint appended. Efficient, with only the raw path as marginal noise.

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, fully-annotated, zero-required-param list tool with complete schema docs, this is largely sufficient: the returned-field enumeration substitutes for the absent output schema. Only pagination/volume behavior and any filtering limits are left unstated.

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 100%, and both params are documented there, including the useful 'Pass the previous reply's next_page' hint. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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 ('List locations') and clarifies the domain ('job sites and offices'), plus enumerates the key fields returned (address, coordinates, active flag, time/attendance usage). That distinguishes it from get_location (single record) and create_location by scope, though it never names siblings 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?

There is no when-to-use guidance, no mention of when to prefer exaktime_get_location for a specific site, and no prerequisites or exclusion conditions. The only usage hint is the raw endpoint path, which does not tell an agent when this tool is the right choice.

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?

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds valuable context beyond them: the nightly refresh cadence, the read-only warehouse source, the pagination behavior, and the underlying GET endpoint. It stops short of covering auth or rate-limit 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?

The description is front-loaded with the purpose, then immediately adds the important freshness caveat, pagination note, and endpoint. It is compact with no wasted sentences.

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 with no output schema but 100% schema description coverage, the description is largely complete: it names returned fields, explains pagination, and discloses the nightly data latency. It could say more about the response shape or default behavior, but the essentials for correct invocation are present.

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 100%, so all five parameters are already documented in the input schema. The description reinforces key behavior such as 'Page with skip/next_skip' and 'linked to a time record id', but does not add parameter semantics beyond what the schema already provides.

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 uses a specific verb and resource: 'List meal break compliance violations', and names the key returned fields (type, date, expected vs actual value). It links the resource to a time record id, making the scope clear, but does not explicitly differentiate from siblings such as exaktime_list_time_records or exaktime_query_odata.

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 provides clear context that the data comes from a read-only OData warehouse refreshed nightly, so today's entries may lag. That is useful usage guidance, but it does not say when to choose this tool over alternatives like query_odata or list_time_records, nor does it state any exclusions.

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 establish the safe read-only profile, yet the description still adds genuinely new behavior: the data comes from a read-only OData warehouse refreshed nightly, so today's entries may lag a day. That freshness caveat materially changes how an agent should interpret empty or stale results. It stops short of describing ordering or what a missing approval means.

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 returned fields, then the freshness caveat, then pagination and the endpoint. Every sentence carries information; only the raw GET path is arguably filler for an agent that cannot change it.

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 compensates by listing the returned fields, the nightly-refresh latency, and the pagination loop, which is enough to call the tool correctly. Missing is any note on default ordering or on how 'approval type' values should be interpreted and compared across employees.

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 100%, so all four parameters and their bounds are already documented, including skip's "pass the previous reply's next_skip". The description's "Page with skip/next_skip" restates that relationship rather than adding new meaning, so it sits at the baseline for a fully documented 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?

The description opens with a specific verb+resource (list pay period/timesheet approvals and sign-offs) and enumerates the returned fields, so an agent knows exactly what comes back. It never distinguishes this from the sibling exaktime_list_timecard_approvals, which is the most likely confusion point.

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 it to see who has not yet signed off" gives one concrete usage context, which is helpful. But there is no when-not guidance and no routing hint against exaktime_list_timecard_approvals, exaktime_list_pay_periods, or exaktime_list_time_records, leaving the agent to infer which approvals listing it needs.

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 readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is already covered. The description adds important behavioral context beyond annotations: the source is a read-only OData warehouse refreshed nightly, meaning data can be up to a day stale, and results are newest first. It does not mention rate limits or auth, but the staleness disclosure is a meaningful addition.

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?

Five compact sentences, front-loaded with what is returned and how it is ordered. Each sentence earns its place by adding scope, downstream use, data freshness, paging, or endpoint context. No redundancy or 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 read-only list tool with no output schema, the description covers returned fields, ordering, downstream id linkage, data freshness, pagination, and the underlying endpoint. Annotations cover safety, and all parameters are documented in the schema. Nothing an agent needs in order to call it 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 description coverage is 100%, so all five parameters are already documented in the schema. The description only adds paging guidance ('Page with skip/next_skip') and ordering, not syntax or meaning beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('List pay periods'), enumerates the returned fields, specifies ordering ('newest first'), and links downstream use of the id to approvals. An agent can distinguish this from sibling list tools such as list_pay_schedules or list_pay_period_approvals 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.

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

Provides clear usage context: use the id to find approvals, be aware that the warehouse is refreshed nightly so today's entries may lag, and paginate with skip/next_skip. It does not explicitly state when to choose this over sibling tools like list_pay_schedules or query_odata, so it falls 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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds the underlying endpoint (GET /v1/Payroll/PaySchedules) and the fields returned, but says nothing about pagination behavior, rate limits, or auth requirements beyond what the schema implies.

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 listing the resource and its salient fields, followed by the endpoint path. Nothing is wasted or buried.

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 two-optional-parameter list tool with annotations covering safety, the description supplies enough: what it lists, the fields of interest, and the endpoint. No output schema exists, and the field list partially compensates; only pagination/return-shape nuance 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 100%: page and page_size are fully documented in the schema, including default and range. The description adds no parameter meaning, so the baseline 3 applies.

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 (list pay schedules) plus the fields returned (frequency, first pay date, pay periods per year, default flag), which distinguishes it from the nearby but different exaktime_list_pay_periods. It does not explicitly name an alternative, 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?

There is no statement of when to use this versus exaktime_list_pay_periods or any other sibling, nor any prerequisites or exclusions. The agent must infer usage entirely from the resource 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?

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds value by naming the concrete return fields (personId, names, work email, employee id, username, contractor/deleted flags) and the endpoint. It omits the behavior a searcher most needs though: whether filters are exact or partial matches, whether they combine as AND, and whether deleted persons are included by default.

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 compact sentences: purpose and filters first, return shape second, endpoint last. No redundancy and nothing 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 no output schema, describing the returned fields is exactly right, and pagination is covered by the schema. What's missing is a note that all six parameters are optional and what happens with an empty filter set — a real ambiguity for a search tool with zero required params, but a minor one.

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 100%, so the schema already defines every parameter including page/page_size pagination and length constraints. The description merely re-lists the four filter fields without adding matching semantics or explaining the pagination parameters, so the baseline 3 applies.

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 ('List or search Person records') and enumerates both the filter fields and the returned fields, plus the underlying endpoint GET /v1/Common/Persons. It hints at scope ('employees and API users'), which partly separates it from exaktime_list_employees, but it never explicitly contrasts with exaktime_get_person or exaktime_list_employees.

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: it can be called as a plain list or narrowed by name/email/employee id. There is no explicit when-to-use / when-not guidance, no mention that exaktime_get_person should be used to fetch a single known person, and no statement about what an unfiltered call returns.

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, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds that this is payroll rate code data and returns the base-rate flag, plus the underlying endpoint path. It does not mention pagination behavior or that results may be split across pages, which the schema covers only indirectly.

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 plus a short endpoint reference; no filler. The endpoint path is marginally useful but mostly redundant for an agent, keeping it just under top marks.

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, zero-required-parameter list operation with full schema coverage and safe annotations, this is nearly complete: it names the resource and the fields returned. Missing only a note about pagination when many rate codes exist.

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 100% and both parameters (page, page_size) already carry clear descriptions including defaults and limits. The description adds nothing about parameters, which is acceptable here, so the baseline of 3 applies.

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 ('List payroll rate codes') and enumerates the fields returned (identifier, name, description, base rate flag), so the agent knows exactly what resource it is getting. It does not explicitly differentiate itself from siblings like exaktime_list_cost_codes, but 'rate codes' is a distinct resource name that maps cleanly to this tool.

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 versus alternatives (e.g. exaktime_list_cost_codes, exaktime_list_pay_schedules, or query_odata for filtering), and no note that this is read-only lookups for payroll setup. The agent must infer usage purely from the resource 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important behavior: the data comes from a read-only OData warehouse refreshed nightly, so today's entries may not appear until tomorrow, and results are ordered newest first. This adds meaningful operational context, though it does not cover rate limits or auth expectations.

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 compact and front-loaded: purpose first, then filters, ordering, source freshness, pagination, and endpoint. Every clause contributes useful context without redundancy.

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 compensates by listing the main returned fields and explaining pagination via skip/next_skip, plus the warehouse freshness caveat. It is nearly complete for a read-only list tool, though it does not describe the full response envelope.

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 100%, so parameter meanings are already fully documented. The description reinforces filtering by date range, person, and location, and notes skip/next_skip pagination and newest-first ordering, but most of this is already present in 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?

The description states a specific verb and resource — list scheduled shifts — and enumerates the returned fields (employee, start/end, title, cost code, location, notes). This is clearly distinct from generic record listing or actual punch retrieval, even without naming a sibling tool.

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 useful filtering and pagination guidance (start date range, person, location, skip/next_skip) and a freshness caveat, but it does not explicitly say when to use this tool versus related siblings like time punches or time records. Usage is implied rather than contrasted.

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?

Beyond the readOnly/non-destructive annotations, the description discloses the data source (read-only OData warehouse), a nightly refresh cadence with the concrete consequence that today's approvals may not appear until tomorrow, and the skip/next_skip pagination contract. That freshness caveat is exactly the kind of trait annotations cannot express; only the response shape is left implicit.

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?

Four compact clauses: purpose and returned fields first, then filtering, then the freshness caveat, then pagination and the endpoint. Every sentence carries distinct information and the most decision-relevant facts are front-loaded.

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 compensates by naming the returned fields and the next_skip pagination token, and the nightly-refresh note prevents an agent from misreading a stale result. The only gap is that field formats and the exact error/empty-result behavior are not described.

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 100%, so top, skip, from_date, to_date and person_id are all already documented with defaults and formats. The description reinforces the date-range and employee filters and the next_skip chaining pattern but adds no format or constraint detail beyond the schema, so baseline 3 applies.

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?

Specific verb+resource ('List daily timecard approvals') plus an enumeration of the returned fields (work date, approval type, approver, employee) makes the purpose unambiguous. It distinguishes itself from pay-period or time-punch siblings through the 'daily timecard approvals' framing and the named OData endpoint, though it never explicitly contrasts with exaktime_list_pay_period_approvals.

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?

'Filter by work date range or employee' implies the normal invocation pattern, and the nightly-refresh caveat tells the agent when results may look incomplete. However, there is no explicit guidance on when to prefer this over siblings like list_pay_period_approvals or query_odata, so selection still requires inference.

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 destructiveHint=false, and the description adds real context beyond them: the source is a read-only OData warehouse refreshed nightly, so today's entries may lag by a day. That freshness caveat is exactly the kind of trait an agent cannot get from annotations. It stops short of describing result shape or total counts.

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 short sentences, front-loaded with what the tool returns before the freshness caveat and paging note. The trailing 'GET /odata/DwTimeOffBalances' is slightly redundant with the stated OData source but is cheap and aids debugging.

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 correctly compensates by naming the returned fields (balance hours, maximum balance, manager) and disclosing the data-lag risk and paging contract. What's missing is only the explicit relationship to the time off requests tool, which is minor for a read-only listing.

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 100%, so all four parameters (top, skip, person_id, plan_name) are already documented, and the description only echoes the skip/next_skip paging pattern. It adds no filter-combination or ordering semantics beyond 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+resource (list time off balances per employee and plan) and enumerates the returned fields, plus the underlying endpoint. It is distinguishable from exaktime_list_time_off_requests by name and by the 'balances' framing, but it never explicitly contrasts the two, which is the one sibling an agent could confuse it with.

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 rather than stated: it tells you to page with skip/next_skip and warns the data is a nightly snapshot, but gives no explicit when-to-use or when-not-to-use versus time off requests or time records. An agent can infer the read-only reporting context but must decide the routing itself.

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?

Adds context beyond the annotations: the data comes from a read-only OData warehouse refreshed nightly, so today's entries may lag until tomorrow — a real caveat an agent would otherwise not know. Missing any statement about response size limits or failure behavior, but the freshness warning is the key disclosure.

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 tight paragraph, purpose front-loaded, followed by filters, data-source caveat, pagination, and endpoint. No redundant or throwaway sentences.

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 enumerates the returned fields, explains the pagination contract (next_skip), and flags data latency. That is everything an agent needs to call it correctly and interpret the results.

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 100%, so every parameter is already documented in the schema. The description restates the filter dimensions but adds no format or behavioral detail beyond what the schema provides, so baseline 3 applies.

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 ('List time off requests') and enumerates the row fields returned (employee, plan, dates, hours, status, comments, manager), which clearly separates it from the sibling balance/approval list tools. An agent can identify what it retrieves 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.

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

Gives concrete conditions — filter by status, person, or start-date range — and explains pagination via skip/next_skip. It does not name an alternative (e.g., exaktime_query_odata) for ad-hoc queries, so this lands just 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 readOnly/openWorld/no-destructive, so the bar is lower; the description still adds real context by disclosing that the source is a read-only OData warehouse refreshed nightly, so today's punches may be missing until tomorrow. It also documents ordering ('newest first') and the pagination loop via next_skip.

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 what the tool returns and how to filter, then the freshness caveat and pagination note; every sentence earns its place. The trailing 'GET /odata/DwTimePunches' endpoint detail is the only borderline 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?

With no output schema, the description still names the returned fields and explains that next_skip comes from the previous reply, which is enough to drive pagination correctly. Only the shape of the response envelope (e.g. presence of a next_skip field name) is left implicit.

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 100%, so every parameter is already documented in the schema; the description's restatement of date/person/location filters and skip/next_skip adds little beyond it. Baseline 3 applies since the schema carries the load.

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 ('List raw clock punches') and enumerates the returned fields, which separates it in spirit from time_records and shifts. It does not explicitly name those siblings, so an agent must infer the boundary rather than being routed.

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?

Offers filtering guidance ('by date range (UTC days), person or location') and pagination instructions, plus a useful freshness caveat, but never states when to prefer this over exaktime_list_time_records or exaktime_list_shifts, which are the closest alternatives.

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 destructiveHint=false, so safety is covered; the description adds genuinely useful behavior: the read-only OData warehouse provenance, the nightly refresh with the consequence that today's data may be missing, newest-first ordering, and the skip/next_skip paging contract. It doesn't describe row shape or limits on the result set, but the added context is substantial.

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?

Four dense sentences, zero filler, and the most decision-relevant content (what a record is, how to filter) comes first, with the staleness caveat and paging details trailing. Nothing could be removed 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?

With no output schema, the description carries the return-shape burden and does so partly by enumerating the fields a record contains and by referencing next_skip as the paging cursor. The remaining gap is that it doesn't say how many rows to expect or what the default projection includes beyond the main columns.

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 100%, so every one of the nine parameters is already documented in the schema. The description only restates the filter dimensions and the paging idiom; it adds nothing on all_fields or active_only, which are the two parameters whose effect is least obvious from a name alone.

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 and then defines the resource concretely: "timecard entries: who worked, when, on which cost code and location, regular/overtime hours." That distinguishes it in substance from the sibling list tools, though it never explicitly contrasts itself with exaktime_list_time_punches or exaktime_list_timecard_approvals, which an agent could easily confuse with it.

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 clear operating context: filter by work date range, person, location, or cost code, newest first, and page with skip/next_skip. It also implicitly scopes use by warning that the source is refreshed nightly so today's entries may lag — a signal that this isn't a real-time tool. It stops short of naming an alternative for real-time punches.

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 read-only/non-destructive/open-world, and the description adds genuinely new behavioral context: the source is a nightly-refreshed warehouse so today's entries may be absent, paging is done via skip/next_skip, and the call maps to GET /odata/{EntitySet}. The freshness caveat is exactly the kind of information an agent cannot get from annotations or 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 with the core purpose and the routing rule, then progressively more detail (entity naming, filter syntax, freshness, paging). Slightly padded by the '(...learning, performance, recruiting, benefits...)' enumeration and two raw URLs, but no sentence is genuinely 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?

No output schema exists, yet the description covers what an agent needs to call correctly: valid entity-set naming, filter dialect with an example, pagination mechanics, and the freshness limitation that affects result interpretation. Nothing material is missing for a 6-parameter generic query tool.

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 100%, so baseline is 3; the description goes beyond it by giving OData v4 $filter syntax with a worked example (startswith(LastName,'Sm') and IsActive eq true), the Dw prefix convention for entity_set, and links to the entity-set list and $metadata schema. It adds real meaning for the trickiest parameter rather than restating field docs.

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 ('Read-only OData query over any Arcoro data warehouse entity set') plus its scope, and explicitly distinguishes it from the sibling tools by positioning it as the catch-all 'for questions the other tools do not cover'. An agent can tell immediately this is the generic escape hatch versus the typed list_/get_ 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?

Gives clear selection context ('questions the other tools do not cover') and enumerates the domain areas and concrete entity set names (DwUsers, DwEquipments, DwExpenses...) so the agent knows what belongs here. It stops short of naming specific siblings to prefer for common cases (e.g. 'use list_employees for basic employee lists'), which is why it isn't 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 flag write/destructive/idempotent/openWorld, and the description adds genuinely new context: read-modify-write semantics ('reads the cost code first and sends the full object') and partial-update behavior ('only the fields you pass change'). This clarifies that despite destructiveHint, unspecified fields are preserved. No mention of permission requirements or error 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?

Two compact sentences, front-loaded with the WRITE marker and partial-update rule, ending with the endpoint. 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 mutation tool with no output schema, the description covers safety profile, update semantics, and endpoint. The only real gap is the undocumented 'identifier' parameter and lack of any note on validation errors.

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 33%, so the description carries real burden. It maps name, cost_type_id, and is_active to their effects, but says nothing about 'identifier', leaving one parameter undocumented in both schema and description; display_option and cost_code_id are covered by the schema itself.

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?

Opens with an explicit verb+resource ('WRITE: change fields of an existing cost code') and enumerates the concrete field changes (rename, cost type, retire). An agent can distinguish it from exaktime_create_cost_code and exaktime_get_cost_code without inspecting either 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?

'existing cost code' plus 'set is_active=false to retire it' tells the agent when this applies versus creating a new record. No sibling is named explicitly, and there is no explicit exclusion, so it stops short of a full 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 destructiveHint=true and idempotentHint=true, but the description adds critical non-obvious behavior: it performs a read-modify-write because Arcoro replaces the job on PUT, and concurrent edits to the same job can silently overwrite each other, so edits must be serialized. That is exactly the operational context an agent cannot infer from 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?

Three sentences, front-loaded with the operation type and the endpoint at the end. Every clause carries distinct information (what changes, how partial updates work, race-condition warning) with no repetition of schema fields.

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 11-parameter mutation tool with no output schema, the description covers the mutation model, null semantics, and concurrency risk, which is enough to call it safely. It stops short of mentioning permission requirements or confirming the response shape, leaving a minor 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: only supplied fields are mutated, null clears nullable fields, and setting location_ids turns off 'available at all locations'. That partial-update framing changes how an agent should reason about the 11 parameters.

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?

Opens with an explicit 'WRITE' marker, a specific verb ('change fields of an existing job') and concrete examples (rename, set dates, assign locations, close via is_active=false). An agent can immediately distinguish this from exaktime_create_job or exaktime_update_location.

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 clear conditions for use: partial update semantics ('Only the fields you pass change'), how to close a job (is_active=false), and how to clear a nullable field (null). It does not explicitly name sibling alternatives, but the guidance for when and how to apply this mutation is unambiguous.

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?

Adds genuine value beyond annotations by disclosing the read-modify-write pattern ('reads the location first and sends the full object'), which tells the agent that omitting a field will not blank it out. However, it never warns about the destructiveHint=true risk surface (e.g. retiring a location detaches employees/time records) and gives no auth or rate-limit context, so the annotation-covered risk profile is only partly elaborated.

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 short clauses, the operation type front-loaded as 'WRITE:', then semantics, then the endpoint. Every sentence 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?

The update semantics and partial-field behavior are well covered, but for a nested-object, 11-parameter mutation the description says nothing about the boolean flags or the onboarding business unit constraint that the schema itself flags as conditionally required. Adequate but with visible 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?

With 11 parameters and only 27% schema description coverage, the description only glosses name, address and is_active. It leaves identifier, comments, latitude/longitude, is_office, is_time_and_attendance and onboarding_business_unit_id completely unexplained, and 'move' is only an oblique hint at the coordinate pair.

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 (change fields of an existing location), the resource, and concrete example mutations (rename, move, new address, retire via is_active=false). The word 'WRITE' and 'existing location' cleanly separate it from exaktime_create_location and exaktime_get_location.

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?

Makes clear this is the edit path for an existing location and even describes the retire idiom (is_active=false), which is a usage decision an agent would otherwise have to guess. It does not explicitly name the alternative tools (create_location for new records, get_location for reads), so it falls short of full 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.