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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the default full-day registration and the optional Hours parameter, which is useful. However, it does not mention any side effects, permissions required, whether changes are reversible, or what success/failure responses look like. For a write operation without annotations, this is a moderate gap.

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 concise sentences, no filler. The purpose is front-loaded, and each sentence adds necessary information: what it does, how to get a required parameter, and the default behavior. Perfectly 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?

For a relatively simple create operation with all parameters described in schema and clear instructions on the key one, the description covers essential execution details. It does not mention output or errors, but no output schema exists and the operation is straightforward. It could slightly improve by distinguishing from create_time_registration, but that 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?

Schema coverage is 100% (all parameters have descriptions), so baseline is 3. The description adds value by explaining that Hours is for partial days and that AbsenceCodeID should come from search_absence_codes, which is not in the schema. This extra context helps agents use the parameters correctly.

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 ('Create an absence registration') and gives concrete examples (vacation, sick leave). This clearly distinguishes it from sibling tools like create_time_registration, and the reference to search_absence_codes preempts a common confusion.

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 instructs to use search_absence_codes to find the AbsenceCodeID, and explains the default full-day behavior with the Hours override. This gives clear, actionable guidance on when and how to invoke the tool as well as a pointer to an alternative for finding the code.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Create a new task' without mentioning permissions, side effects, reversibility, validation behavior, or expected outcomes. This is a significant gap for a mutating tool with zero annotation coverage.

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 consists of two succinct sentences, front-loading the core purpose and then adding the crucial prerequisite. There is no wasted wording, and the structure is efficient and easy to scan.

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 complex mutation tool with 11 parameters, 7 required, no output schema, and no annotations. The description only provides a two-sentence overview. It omits guidance on how to source HourlyRateID (e.g., via get_hourly_rates), what the response format is, error handling, and other lookups. This is inadequate for an agent to call it correctly, especially given the absence of structured metadata.

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 11 parameters already have descriptions in the schema. The tool description adds no extra semantics, such as parameter relationships or defaults for optional fields like IsBillable. Per the baseline rule for high coverage, a 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 clearly states the verb-resource relationship: 'Create a new task (phase) on a project.' It also identifies the prerequisite lookup tool (search_projects), which helps distinguish it from read-only search tools. However, it does not explicitly contrast with other create tools like create_time_registration, though the resource is different.

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 explicit guidance to use search_projects first to obtain the ProjectID, which is a concrete prerequisite for correct invocation. It does not mention when not to use this tool or alternatives for sub-tasks, but the prerequisite is a valuable usage hint.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions creating a registration but does not describe the effect (e.g., whether it creates a draft, requires approval, or has side effects on timesheet status). It also lacks any mention of permissions or reversibility, leaving significant behavioral unknowns for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the tool's purpose and immediately provides a practical usage hint. It contains zero fluff and earns every word, making it ideal for quick agent comprehension.

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 tool has 6 parameters (3 required), no output schema, and no annotations, the description is too sparse for full contextual completeness. It only addresses the prerequisite of finding TaskID, but omits details about the registration workflow, potential errors, or interaction with timesheet submission. The agent is left without important context about the tool's role in the broader time-registration process.

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

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

The schema provides 100% coverage with descriptions for all parameters, so the baseline is 3. The tool description adds no extra parameter context beyond the schema, merely stating the purpose and the need for TaskID. It does not add value in clarifying format, defaults, or relationships between 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?

The description clearly states the tool's action ('Create a new time registration') and its target ('on a task'), distinguishing it from update/delete operations. It also names a critical prerequisite (search_tasks to get TaskID), which leaves no ambiguity about the tool's role.

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 explicitly instructs the user to call search_tasks first, providing a clear contextual step for correct usage. However, it does not explicitly contrast with alternatives like update_time_registration or delete_time_registration, leaving some implicit inference about when not to use this tool.

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?

With no annotations, the description must carry the full burden of behavioral disclosure. It only states 'Delete' without noting that the action is permanent, irreversible, may require permissions, or what error conditions exist. A destructive tool should warn about consequences, which is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with zero waste. It delivers the action and subject immediately and is appropriately concise for a simple tool.

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?

Although the tool is simple with one parameter, as a destructive operation it lacks essential context about permanence, side effects, and possible failure modes. With no annotations and no output schema, the description should provide more behavioral detail to be considered complete.

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

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

The schema covers the single parameter 'id' fully (type, format, pattern, description). The description adds nothing beyond 'by GUID', which is already implied. With 100% schema description coverage, the baseline of 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 uses a specific verb ('Delete'), a clear resource ('time registration'), and the method ('by GUID'). It unambiguously identifies the operation and distinguishes it from sibling tools like create_time_registration and update_time_registration.

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 is provided on when to use this tool vs. alternatives. There is no mention of prerequisites, safety checks, or situations where deletion might be inappropriate. The description is purely declarative and offers no exclusions or routing.

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

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

No annotations are provided, so the description carries the full burden. It uses 'Get' (implying a read operation) and lists the return content, which is useful. However, it does not explicitly state that the operation is side-effect-free, nor does it mention any potential errors, permissions, or rate limits. The return field list provides some behavioral context, but the non-mutating nature is only implied, not disclosed.

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 sentences: the first states the purpose and return fields succinctly, the second gives the usage prerequisite. It is front-loaded with the core action and includes no wasted words, making it highly efficient.

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

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

For a simple tool with one parameter, the description is largely complete: it states the resource, lists all return fields, and explains how to obtain the required ID. It does not mention behavior when no rates exist (e.g., empty array) or any pagination, but these are minor gaps for a tool of this complexity.

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

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

The schema covers the single parameter (contractId) with a basic description, and coverage is 100%. The description adds value by telling the agent to fetch the contractId via get_project_contracts, which is extra semantics beyond the schema. This warrants a 4 rather than 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?

The description clearly states the tool retrieves all hourly rates for a specific contract and lists the returned fields (rate name, amount, currency, type, active status). It is specific about the resource (contract) but does not explicitly contrast it with the sibling get_hourly_rates, so it misses the explicit sibling differentiation that would earn a 5.

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

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

The description gives explicit guidance on the prerequisite step: 'Use get_project_contracts first to find the contractId.' This tells the agent when and how to obtain the required parameter. However, it does not address when to choose this tool over get_hourly_rates or other alternative tools, so it falls short of 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that the call is read-only, whether authentication is required, or what happens if no user is authenticated (e.g., null or error response). For a simple getter, some of this is implied, but the lack of explicit disclosure is a notable gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that immediately states the action and the data returned. No fluff or unnecessary detail, and the core purpose is 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?

Given zero parameters and no output schema, the description sufficiently covers what the tool does and what it returns. There are no missing elements that would prevent an agent from calling it correctly. The only minor gap is behavioral (auth/errors), but that is already penalized in that dimension.

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

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

The tool has zero parameters, and the schema is empty with 100% coverage (trivially). Per the rule, with 0 parameters the baseline is 4. The description appropriately does not discuss parameters since there are none, so no additional semantics are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Get') and resource ('currently authenticated Timelog user'), and specifies the returned fields (name, email, department). This uniquely distinguishes it from all sibling tools, none of which appear to retrieve user info.

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 implicitly defines the use case—whenever the agent needs the current user's identity or basic profile. There are no competing sibling tools for user retrieval, so no explicit when-not guidance is required. The context is clear enough for an agent to select it appropriately.

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?

No annotations are provided, so the description carries the full burden. It indicates a read operation but does not disclose return format, pagination, permissions, or error handling. This is a significant gap for a tool lacking structured behavioral metadata.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no extraneous words. The core purpose and scope are stated immediately, making it quick to parse.

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 should clarify what 'financial data' returns (e.g., list of registrations with billable flags, aggregates). It does not, leaving the agent unsure of the response structure or how to interpret 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 description coverage is 100% and both startDate/endDate are documented with format hints. The description adds no extra parameter meaning beyond 'date range', so it meets the baseline for full schema coverage but does not elevate it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Get'), resource ('financial data'), and scope ('time registrations in a date range'). It clearly differentiates from siblings like get_registrations_by_date_range by focusing on billable/invoice status rather than raw registrations.

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 implies usage when financial data for time registrations is needed, but it does not explicitly compare to alternatives or provide when-not conditions. Context is clear from the purpose but exclusions and alternative tool selection are absent.

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?

With no annotations, the description carries the full burden. It does disclose the source of the contract value (from payment plan), the behavior of hourly rates for FP contracts (typically 0), and a recommendation to use financial data for effective rates. This is useful behavioral context, but it does not describe read-only nature (though 'get' implies it), error conditions, or any side effects. It adds moderate transparency but not comprehensive.

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 concise, consisting of two sentences. The first sentence front-loads the core purpose and contents, the second provides a practical note about hourly rates. No filler or redundant information. It is well-structured and earns its keep.

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 description covers the main elements an agent needs: what data is returned (value, schedule, tasks, rates), a key caveat about FP hourly rates, and a hint on how to calculate effective rates. There is no output schema, so the description effectively communicates the data scope. Minor omissions like return format or pagination are not critical for a get-details tool. Overall, it is reasonably complete for the tool's complexity.

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

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

Schema description coverage is 100%, so both parameters (contractId, projectId) are already described in the schema. The description adds no new meaning to the parameters themselves; it only says contractId comes from get_project_contracts (which is already in the schema). The description does not compensate with additional parameter context, so the baseline of 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 clearly states the tool's purpose: it retrieves complete details for a fixed-price contract, enumerating the specific data components (contract value, payment schedule, tasks/phases, hourly rates). This is a specific verb+resource. It does not explicitly differentiate from sibling tools like get_contract_hourly_rates or get_project_contracts, but the enumeration of contents makes the purpose distinct enough.

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

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

The description provides some implicit usage guidance: it indicates that for fixed-price contracts hourly rates are typically zero and suggests leveraging overall project financial data for effective rates. However, it does not explicitly state when to choose this tool over its siblings (e.g., get_project_contracts for list vs. this for details). The guidance is implied (it's for FP contracts), but not formally stated as usage criteria or 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?

With no annotations provided, the description carries full behavioral burden. It discloses the return payload fields (name, amount, currency, customer, active status) and confirms pagination behavior. It does not explicitly state read-only semantics or auth requirements, but for a 'get' tool with this level of detail, it is fairly transparent. The lack of explicit safety info keeps it from a 5.

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 three tightly written sentences with no fluff. Purpose is front-loaded, return fields follow, and usage notes come last. Every sentence contributes value and the structure is efficient for cognitive parsing.

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

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

For a simple read-only tool with 3 optional parameters, the description covers the essential calling information: what it returns, how to filter, and that results are paginated. Since the schema already explains pageSize and pageNumber defaults, the description is sufficiently complete. It only lacks a note on when to prefer this over get_contract_hourly_rates, which is 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 all three parameters already have clear descriptions. The tool description adds no new semantic detail beyond restating 'searchText' as a filter and mentioning pagination, which the schema already covers. This aligns with the baseline of 3 for high-coverage schemas.

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 starts with a clear verb+resource: 'Get hourly rates defined in Timelog.' It lists the exact return fields (rate name, amount, currency, customer, active status) and mentions filtering and pagination. This clearly distinguishes it from the sibling get_contract_hourly_rates by specifying the source context ('defined in Timelog').

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 some usage hints: 'Use searchText to filter by name' and 'Results are paginated.' However, it does not explicitly explain when to use this tool versus get_contract_hourly_rates, a closely named sibling. There is no when-not or alternative routing. The guidance is implied at best, not 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a list of legal entities with specific fields, which is useful. However, it does not explicitly state that the operation is read-only (though 'Get' implies it), nor does it mention any authentication, pagination, or error behavior. This is adequate for a simple list operation but leaves some behavioral traits unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence. It front-loads the core action ('Get all legal entities'), immediately scopes to the organization, and lists the return fields efficiently. No wasted words or redundant information.

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

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

For a zero-parameter, no-output-schema tool, the description is sufficiently complete: it states what the tool returns and the scope. It does not mention pagination or error cases, but for a simple list endpoint this is not a significant gap. Overall, an agent can call it correctly with the information provided.

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

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

The tool has zero parameters, so the schema coverage is trivially 100%. Per the calibration, a baseline of 4 is appropriate for tools with no parameters. The description does not need to add parameter semantics, and it avoids adding any unnecessary detail.

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 clearly states the verb 'Get' and the resource 'legal entities', scoped to the 'Timelog organization'. It also enumerates the returned fields (ID, name, active status, currency, country), which distinguishes it from other get_* tools by specifying exactly what information is retrieved.

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 makes clear that this is the tool for retrieving all legal entities in the organization. It provides clear context and implies usage for any request needing legal entity data. However, it does not explicitly mention when to use it over alternatives, though no direct sibling for legal entities exists, so the ambiguity is minimal.

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?

With no annotations provided, the description must carry the behavioral disclosure. It lists the return fields, which is useful, but it does not explicitly state that this is a read-only operation, nor does it mention error behavior (e.g., what happens if the project does not exist) or any authentication requirements. The description is adequate for a simple getter but leaves these aspects 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?

A single, compact sentence that places the primary action and selector upfront, followed by a list of returned fields. Zero filler; every element contributes to understanding the tool's purpose and output.

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 getter with one required parameter and no output schema, the description adequately covers the return payload by listing the fields. It omits minor details like error handling, but these are not critical for a straightforward lookup tool. The level of detail is appropriate for the tool's complexity.

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

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

Schema description coverage is 100% because the sole parameter 'projectId' already has a clear description ('The project ID to look up'). The tool description adds no additional semantic detail beyond what the schema provides—it merely restates the lookup key. Baseline of 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 clearly states the action ('Get'), the resource ('project details'), and the selector ('by project ID'). It also enumerates the specific fields returned (name, project number, customer, etc.), making the purpose unambiguous and distinct from sibling tools like search_projects, which imply searching rather than direct lookup.

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 project ID' implies that a known ID is required, which is a clear usage condition. However, it does not explicitly mention alternatives such as search_projects when the ID is unknown, nor does it state when not to use this tool. The guidance is implied rather than explicit, so it falls short of a 4.

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?

No annotations are provided, so the description carries the full disclosure burden. It specifies the exact output fields, which is helpful, but it does not disclose any side effects, permissions, pagination, or error behavior. Since 'Get' implies a read-only operation, the description is not misleading, but it adds minimal behavioral context beyond the name and field list, earning a baseline score.

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 sentences with zero fluff. The primary purpose leads, followed by a compact enumeration of returned fields, and ends with a practical cross-reference to a sibling tool. Every sentence earns its place, and the structure is entirely front-loaded for quick parsing.

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 list tool with one parameter and no output schema, the description is fully self-sufficient: it names the resource, enumerates the exact return fields, and even tells the agent how to proceed with the results. Nothing an agent needs to call it correctly and interpret the output is missing. The cross-reference to get_contract_hourly_rates further completes the workflow context.

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, projectId, and the schema description already fully explains it as 'The project ID to list contracts for.' The description does not add any additional syntax, format, or constraints beyond that. With 100% schema coverage, the baseline of 3 applies, and the description correctly avoids redundancy.

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 (Get) and resource (all contracts for a project), and enumerates the returned fields (contract ID, name, type, status, main contract flag), making it unmistakably distinct from siblings like get_contract_hourly_rates and get_fixed_price_contract_details. The inclusion of the contract type enum values adds precision. An agent can immediately determine what this tool does 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?

The description clearly implies when to use this tool—when you need a list of a project's contracts—and explicitly tells the agent to use the returned contractId with get_contract_hourly_rates to get rates, which is a valuable follow-up path. However, it doesn't explicitly state when NOT to use it or mention alternatives like get_fixed_price_contract_details for detailed fixed-price info, so it falls just short of exhaustive 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?

With no annotations, the description must disclose behavioral traits. It lists return fields, which is helpful, but does not mention pagination behavior (schema includes pageSize and pageNumber) or explicitly state it is a read-only operation. The claim 'Get all tasks' combined with default page size of 10 could mislead about output size, though not a strict contradiction.

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, front-loaded with the core purpose and return contents, followed by a pragmatic sourcing hint. Every word earns its place; no 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?

For a straightforward getter, the description covers return fields and projectId sourcing. However, it omits pagination semantics (given schema has pageSize/pageNumber) and does not distinguish usage from search_tasks. No output schema exists, so the listed fields mitigate that, but the ambiguity around 'all' vs pagination is a 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%, so the description need not restate parameter meanings. It adds a practical hint about sourcing projectId, which is a usage note rather than parameter semantics. This meets the baseline without exceeding it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get'), the resource ('all tasks (phases) for a project'), and enumerates the returned fields (task IDs, names, parent hierarchy, fixed-price status, billable defaults). It distinguishes from search_tasks implicitly by focusing on 'all tasks for a project' rather than searching, but does not explicitly contrast 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?

The description provides a useful hint on sourcing projectId ('from get_project or from time registrations'), giving practical context. However, it does not state when to prefer this tool over search_tasks or when not to use it, leaving the choice 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 are absent, so the description carries the full burden. It indicates a read operation ('get'), but does not disclose return format, pagination, ordering, filtering behavior, or any side effects. It is not misleading, but it provides minimal behavioral detail beyond the implicit non-mutating nature of 'get'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that immediately conveys the core functionality. There is no extraneous text, and the essential information is front-loaded. It is efficient and to the point.

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 simplicity of the tool (2 parameters, no output schema), the description is adequate for an agent to understand its primary purpose. However, it lacks details on return value, potential error conditions, or how it relates to similar tools like get_weekly_registrations. A brief note on response structure or use case would improve completeness, but for a minimal read tool, it is acceptable.

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 both parameters with format. The description adds no additional meaning or constraints. Baseline 3 is appropriate because the schema handles semantics effectively, and the description does not need to repeat it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (get) and the resource (time registrations) with a specific scope (between two dates). It is unambiguous and directly reflects the tool name. However, it does not explicitly differentiate from sibling get_weekly_registrations, though the date-range qualifier implicitly distinguishes 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?

No guidance is provided on when to use this tool versus alternatives like get_weekly_registrations or get_timesheet_status. There is no mention of context, exclusions, or prerequisites. The usage is only implied by the parameter names (date range) but not explicitly 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?

With no annotations, the description carries the full burden. It discloses that it defaults to the authenticated user and that omitting userId returns all employees (manager view). It also mentions optional filters. However, it does not disclose the response format, any side effects (though it's a GET), or potential limits like pagination. This is a moderate level of transparency.

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 concise, only two sentences. It front-loads the core purpose and then provides usage details in a logical order. Every sentence adds value without redundancy. This is well-structured and efficient.

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

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

The tool has no output schema, so the description must explain what the response contains. It only says 'status' without defining what that means or describing the output structure. It also does not mention pagination, error cases, or how the result relates to other timesheet tools. Given the tool's relative complexity (6 parameters, filters), this is a significant 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 per the rubric the baseline is 3. The description adds some context beyond the schema: the default behavior of userId, the manager view when omitted, and the fact that filters can be combined. This provides extra meaning but does not drastically improve understanding of each parameter.

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 clearly states the purpose: 'Get weekly timesheet status.' It specifies the resource (weekly timesheet) and the action (get). It also clarifies the default scope (authenticated user) and the ability to filter. However, it does not explicitly differentiate from sibling tools like get_weekly_registrations, so it's not a 5.

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

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

The description provides usage context: default to authenticated user, pass userId for specific employee, omit for manager view, and filters by departmentId, approverId, legalEntityId. This gives concrete guidance on when to use different parameter combinations. However, it does not mention alternatives or when not to use this tool, so the guidance is partially complete.

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?

With no annotations provided, the description carries the full burden. It identifies the operation as a read ('Get'), which is non-destructive. It also adds the behavioral constraint that the input must be the Monday of the week, which is valuable. However, it does not disclose any further behavior such as error handling, permission requirements, or response format. For a simple read operation, 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 sentences with zero wasted words. It front-loads the purpose and then states the required input format. Every sentence earns its place, and the structure is perfectly sized for the tool's simplicity.

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 no output schema, the description is essentially complete: it states what it does and what input to provide. It does not explain the return format, but that is often assumed for a get operation. The only minor gap is the absence of differentiation from the date-range sibling, though that falls under usage guidance. Overall, an agent has enough context to call this tool correctly.

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% — the schema already documents startDate as 'Monday of the week, format YYYY-MM-DD'. The description repeats this information without adding new meaning. The parameter semantics are fully captured in the schema, so the description adds no extra value beyond 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?

The description clearly states the verb 'Get' and the resource 'time registrations', and narrows the scope to 'a specific week'. This distinguishes it from the sibling get_registrations_by_date_range, as the tool is specifically for weekly data. The purpose is unambiguous and specific.

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 implies usage context ('for a specific week') and instructs the agent to provide the Monday date, but it does not explicitly mention when not to use this tool or point to an alternative like get_registrations_by_date_range. The guidance is clear enough to infer the intended use case, but lacks explicit exclusions or alternative routing.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It only states that it searches and returns AbsenceCodeID, but does not mention whether searchText is optional (though schema does), whether searches are partial/case-sensitive, or whether multiple results are returned. This is minimal for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, information-dense sentence that front-loads the action and purpose with no wasted words.

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

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

For a simple search tool with one optional parameter and no output schema, the description covers the core purpose and output usage but omits practical details like behavior with an empty searchText or possible multiple results. It is adequate but has room to be more explicit.

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% with a description for searchText, so the baseline is 3. The description adds valuable examples (Ferie, Sygdom) that clarify the expected input format, exceeding the schema's generic description.

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 clearly states the action (search) and resource (absence codes), provides concrete examples (Ferie, Sygdom), and explains the output's purpose (returning AbsenceCodeID for create_absence_registration). It distinguishes itself from sibling search tools like search_tasks and search_projects by the resource type.

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 ties the tool to the workflow of creating absence registrations ('needed for create_absence_registration'), which tells an agent when to use it. It does not explicitly name alternatives or exclusions, but the resource specificity makes the intended usage clear.

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?

With no annotations provided, the description bears the full burden of behavioral disclosure. It implies a read-only search operation (via the verb 'search') and lists the return fields, which is useful. However, it does not explicitly state that the operation is non-mutating, nor does it mention any rate limits, result caps, or ordering behavior. The content is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the action ('Search for projects'), specifies the resource, and lists the return fields. There is zero filler; every word carries meaning. It achieves maximum clarity in minimal space.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the essential information: it states the search capability, the input criteria, and the output fields. It does not mention pagination or result limits, which could be relevant, but for a straightforward search tool the description is sufficiently complete for an agent to invoke it correctly.

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

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

The schema describes the single parameter 'searchText' as 'Project name or number to search for' with 100% coverage. The description adds no new meaning beyond restating the same criteria ('by name or number'). Per the baseline for high schema coverage, this is adequate but not enhanced.

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 clearly states the tool's purpose: 'Search for projects by name or number.' It specifies the resource (projects) and the search criteria, and lists the return fields (IDs, names, numbers, customer info). This effectively distinguishes it from siblings like get_project (direct fetch by ID) and search_tasks (different resource).

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that get_project should be used when the project ID is already known, or any other routing instructions. The agent is left to infer usage from the name and generic search semantics, which is insufficient given the many sibling tools.

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?

With no annotations, the description must carry the behavioral burden. It states the return value (task IDs needed for time registration) but does not disclose other behaviors such as result limits, sorting, pagination, or auth requirements. Since it's a read-only search operation, the description is somewhat adequate but lacks depth.

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 with no fluff. The purpose is front-loaded, and the second sentence gives a practical usage tip. Perfectly concise.

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 search tool, the description is reasonably complete: it explains the purpose, the return value, and hints at parameter usage. The lack of explicit pagination or result count information is minor given the tool's simplicity and the schema already documenting parameters.

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 the baseline is 3. The description adds an extra hint that searchText can filter by project name (which is not in the schema's description of 'task name or task number') and suggests using it. This provides additional semantic value 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?

The description clearly states the tool searches for tasks the user can register time on and that it returns task IDs for time registration. This is specific and distinguishes it from search_projects or get_project_tasks, though it doesn't explicitly name these 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 description implies when to use the tool (when you need task IDs for time registration) and provides a hint to use searchText for filtering. However, it doesn't explicitly mention alternatives or when not to use it, leaving some ambiguity in scenarios where other search tools might be more appropriate.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes a write/action (submit) but does not mention side effects, such as whether it changes the timesheet status, whether existing submissions are rejected, or whether any prerequisites (like having registrations for the range) exist. This is a significant gap for a mutating tool, similar to the update_drive example.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler. It front-loads the core action and scope, making it easy for an agent to parse quickly. Every word earns its place.

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 submission action with no annotations and no output schema, the description is incomplete. It fails to explain prerequisites (e.g., whether time registrations must exist first), what happens on success or failure, or whether it can be repeated. The sibling list includes create_time_registration, suggesting a workflow dependency, but this is not addressed. An agent lacks information needed to confidently invoke the tool in a multi-step process.

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

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

The schema provides full descriptions for all four parameters (startDate, endDate, comment, employeeUserId), achieving 100% coverage. The description only mentions 'a date range', which aligns with startDate/endDate but adds no new semantics. Per baseline rules, when schema coverage is high, a score of 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 clearly states the action: 'Submit timesheet for approval' with a scope of 'a date range'. This identifies the verb and resource precisely and distinguishes it from other tools like create_time_registration or get_timesheet_status by its intent to submit rather than create or query. However, it doesn't explicitly call out sibling alternatives, so it stops short of a 5.

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

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

The description implies when to use the tool (when you have a date range and want to submit for approval) but provides no explicit guidance on when not to use it or alternatives. There's no mention that this should follow creating time registrations or that it complements get_timesheet_status. Guidance is only implied through the verb 'submit'.

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?

No annotations are provided, so the description carries the full burden of describing behavior. It only says 'Update', which implies mutation, but gives no information about permissions, reversibility, whether the update is partial or full, or what the response looks like. For a mutating tool, this is a significant gap that leaves the agent uncertain about side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the core operation and key fields. There is no unnecessary information or redundant wording, making it easy to parse quickly.

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 an update tool with no annotations and no output schema, so the description needs to compensate. It does not state whether the update is partial or full, what the return value is, or any prerequisites (e.g., which identifiers are required for lookup). The description is too sparse to fully prepare an agent for a correct call, especially given the 7 parameters.

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

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

The input schema covers 100% of parameters, so the baseline is 3. The description lists some updatable fields (hours, comment, date, billable) but omits JiraId and the identifier fields (TimeRegistrationID, TaskID). It doesn't clarify which fields are actually updatable vs. identifiers, adding only marginal value beyond the schema's own parameter descriptions.

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 clearly states the verb 'Update' and the resource 'time registration', and lists the specific fields affected (hours, comment, date, billable status). This makes the tool's purpose unambiguous and distinguishes it from sibling tools like create_time_registration and delete_time_registration.

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 specifies the operation applies to an 'existing' time registration, which implies it is not for creating new ones. This gives clear context for when to use it, but it does not explicitly name the alternative (create_time_registration) or state when not to use it. The context is clear but without explicit exclusions.

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