The Tripletex MCP Server connects AI assistants to the Tripletex accounting API, enabling natural language management of time tracking, projects, timesheets, and invoices.
Authentication & User Info
Get information about the currently authenticated user
Projects & Activities
Search for projects by name, number, status, or assigned employees
Search for activities (e.g. development, meetings, vacation) by name or type
Access recently used projects and activities for quick logging
Time Tracking
Create, read, update, and delete timesheet entries
Search entries across a date range with filters for project, activity, or employee
Retrieve total hours logged for an employee over a period
Time Clock (Real-time Timers)
Start and stop live timers for a project/activity
Check the currently active timer for an employee
Timesheet Approval
Search weekly and monthly timesheet statuses
Complete, approve, or reopen timesheet weeks and months
Customer Invoices (Outgoing)
Search by date range, customer, or invoice number
Retrieve a single invoice by ID
Supplier Invoices (Incoming)
Search by date range, supplier, or invoice number
Retrieve a single invoice by ID
Get invoices pending approval
Approve or reject single or multiple invoices (rejection requires a comment)
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Tripletex MCP Server Log 5 hours on the website redesign project for today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server for the Tripletex accounting API. Enables AI assistants to log hours, manage timesheets, and handle invoices through natural language.
Time tracking — log hours, start/stop timers, search entries
Projects & activities — look up projects and activities by name
Timesheet approval — complete, approve, and reopen weekly/monthly timesheets
Invoices — search outgoing and incoming invoices
Supplier invoice approval — approve or reject supplier invoices
Related MCP server: fiken-mcp
You need two tokens from Tripletex:
Consumer token — provided after API 2.0 registration
Employee token — created by an admin in Tripletex under user settings > "API access"
The server automatically creates a session token on first use (valid 1 day).
Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"tripletex": {
"command": "npx",
"args": ["-y", "tripletex-mcp"],
"env": {
"TRIPLETEX_CONSUMER_TOKEN": "<your-consumer-token>",
"TRIPLETEX_EMPLOYEE_TOKEN": "<your-employee-token>"
}
}
}
}Or to install from GitHub directly:
{
"mcpServers": {
"tripletex": {
"command": "npx",
"args": ["-y", "github:adriantr/tripletex-mcp"],
"env": {
"TRIPLETEX_CONSUMER_TOKEN": "<your-consumer-token>",
"TRIPLETEX_EMPLOYEE_TOKEN": "<your-employee-token>"
}
}
}
}Variable | Required | Description |
| Yes | API consumer token |
| Yes | Employee token |
| No | Company ID (default: |
| No | API base URL (default: |
whoami — Get information about the currently authenticated user
search_projects — Search for projects by name or other filters
search_activities — Search for activities (e.g. development, meetings, vacation)
search_timesheet_entries — Search timesheet entries for a date range
get_timesheet_entry — Get a single timesheet entry by ID
create_timesheet_entry — Log hours for a project/activity/date
update_timesheet_entry — Update an existing timesheet entry
delete_timesheet_entry — Delete a timesheet entry
get_total_hours — Get total hours for a date range
get_recent_projects — Get recently used projects
get_recent_activities — Get recently used activities for a project
start_time_clock — Start a real-time timer
stop_time_clock — Stop a running timer
get_current_time_clock — Get the currently running timer
search_timesheet_weeks — Search weekly timesheet status
approve_timesheet_week — Approve a timesheet week
complete_timesheet_week — Mark a week as complete
reopen_timesheet_week — Reopen a completed/approved week
get_timesheet_month — Get monthly timesheet status
approve_timesheet_month — Approve a timesheet month
complete_timesheet_month — Mark a month as complete
reopen_timesheet_month — Reopen a completed/approved month
search_invoices — Search outgoing (customer) invoices
get_invoice — Get a single outgoing invoice by ID
search_supplier_invoices — Search incoming (supplier) invoices
get_supplier_invoice — Get a single supplier invoice by ID
get_supplier_invoices_for_approval — Get invoices pending approval
approve_supplier_invoice — Approve a supplier invoice
approve_supplier_invoices — Approve multiple supplier invoices
reject_supplier_invoice — Reject a supplier invoice (comment required)
reject_supplier_invoices — Reject multiple supplier invoices (comment required)
npm install
npm run buildISC
Approve a supplier invoice.
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceId | Yes | Supplier invoice ID to approve | |
| comment | No | Optional approval comment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral context. It states the action but doesn't disclose side effects (e.g., invoice status changes, notifications sent), permissions required, whether approval is reversible, or what happens on success/failure. This is inadequate 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 with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for the tool's complexity.
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 annotations and no output schema, the description is insufficient. It doesn't explain what happens after approval (e.g., invoice moves to paid status, triggers payment), error conditions, or return values. The agent lacks critical context for proper invocation.
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 fully documents both parameters (invoiceId and comment). The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('approve') and resource ('supplier invoice'), making the purpose immediately understandable. It distinguishes from siblings like 'reject_supplier_invoice' by specifying approval action, though it doesn't explicitly contrast with 'approve_supplier_invoices' (plural).
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. It doesn't mention prerequisites (e.g., invoice must be in pending state), when not to use it, or how it differs from 'approve_supplier_invoices' (batch approval). The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Approve multiple supplier invoices at once.
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceIds | Yes | Comma-separated invoice IDs | |
| comment | No | Optional approval comment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't mention required permissions, whether approval is reversible, system state changes, error handling, or response format. For a mutation tool with zero annotation coverage, this is a significant 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, efficient sentence with zero wasted words. It's appropriately sized for a simple batch operation and front-loads the key information (approve multiple invoices).
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 annotations and no output schema, the description is inadequate. It doesn't explain what happens after approval, return values, error conditions, or system implications. The presence of sibling tools like 'reject_supplier_invoices' and 'get_supplier_invoices_for_approval' suggests this exists in a workflow context that isn't explained.
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 completely. The description doesn't add any meaning beyond what's in the schema - it doesn't explain invoice ID format, comment usage, or batch limitations. Baseline 3 is appropriate when 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?
The description clearly states the action ('approve') and resource ('supplier invoices'), and specifies 'multiple... at once' which distinguishes it from the singular 'approve_supplier_invoice' sibling tool. However, it doesn't explicitly mention what approval entails or the system context.
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 'approve_supplier_invoice' (for single invoices) or 'reject_supplier_invoices'. The description implies batch processing but doesn't specify prerequisites, constraints, or ideal scenarios for batch approval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Approve a timesheet month.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Timesheet month ID | |
| employeeIds | No | Employee ID(s), comma-separated | |
| monthYear | No | Month (e.g. '2026-02') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose permissions needed, side effects (e.g., if approval is irreversible), rate limits, or response format, leaving critical gaps 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 with no wasted words, making it easy to parse. However, it's overly terse, potentially under-specifying for a tool with multiple parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, return values, error conditions, and differentiation from siblings, failing to compensate for the missing structured data.
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 parameters are documented in the schema. The description adds no additional meaning beyond implying approval of a timesheet month, which aligns with the schema but doesn't enhance understanding of parameter usage or interactions.
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 the action ('approve') and resource ('timesheet month'), which is clear but minimal. It doesn't differentiate from sibling tools like 'approve_timesheet_week' or 'complete_timesheet_month', leaving ambiguity about scope and 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?
No guidance is provided on when to use this tool versus alternatives such as 'approve_timesheet_week' or 'complete_timesheet_month'. The description lacks context about prerequisites, timing, or exclusions, offering no help for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Approve a timesheet week.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Timesheet week ID | |
| employeeId | No | Employee ID | |
| weekYear | No | ISO week-year (e.g. '2026-07') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. 'Approve' implies a write/mutation operation, but the description doesn't disclose permissions needed, whether approval is reversible, what happens after approval (e.g., notifications, status changes), or any rate limits. This leaves significant gaps 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 with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for the tool's apparent complexity.
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 annotations and no output schema, the description is inadequate. It doesn't explain what happens after approval, potential side effects, error conditions, or return values. Given the complexity implied by three parameters and the lack of structured safety information, more context is needed.
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 fully documents all three parameters. The description adds no parameter information beyond what's in the schema, providing no additional context about parameter relationships, dependencies, or usage examples. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Approve') and resource ('a timesheet week'), making the purpose immediately understandable. It distinguishes from obvious alternatives like 'reject' or 'complete' operations, though it doesn't explicitly differentiate from sibling tools like 'approve_timesheet_month' beyond the resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., timesheet must be submitted), conditions for approval, or when to choose 'approve_timesheet_week' over 'complete_timesheet_week' or 'approve_timesheet_month' from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a timesheet month as complete.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Timesheet month ID | |
| employeeIds | No | Employee ID(s), comma-separated | |
| monthYear | No | Month (e.g. '2026-02') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Mark as complete' implies a mutation, but it doesn't disclose behavioral traits such as required permissions, whether the action is reversible (see sibling 'reopen_timesheet_month'), side effects, or error conditions. The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, though brevity may contribute to gaps in other dimensions. 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?
Given the tool's mutation nature, lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, return values, or error handling. Sibling tools suggest complex workflows (e.g., 'reopen_timesheet_month'), but the description doesn't address this context, leaving significant gaps for an AI agent.
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 three parameters (id, employeeIds, monthYear). The description adds no meaning beyond what the schema provides—it doesn't explain parameter relationships (e.g., if id is used, others might be ignored) or usage nuances. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark a timesheet month as complete' clearly states the action (mark as complete) and resource (timesheet month). It distinguishes from siblings like 'approve_timesheet_month' or 'reopen_timesheet_month' by specifying the 'complete' state, though it doesn't explicitly contrast with them. The purpose is specific but could be more differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., timesheet must be in a certain state), exclusions, or comparisons to siblings like 'complete_timesheet_week' or 'approve_timesheet_month'. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a timesheet week as complete.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Timesheet week ID | |
| employeeId | No | Employee ID | |
| weekYear | No | ISO week-year (e.g. '2026-07') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Mark as complete' implies a state change mutation, but it doesn't disclose behavioral traits like whether this requires specific permissions, if it's reversible, what happens to associated data, or any rate limits. This leaves significant gaps for an agent to understand the tool's 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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral implications, usage context relative to siblings, and what happens upon completion. Given the complexity of timesheet operations and rich sibling tools, more guidance is needed for an agent to use this effectively.
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 fully documents all three parameters. The description adds no additional meaning about parameters beyond implying a timesheet week context. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with any extra insights.
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 ('Mark as complete') and resource ('timesheet week'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'complete_timesheet_month' or 'approve_timesheet_week', which would require more specific context about what 'complete' means versus 'approve' or 'reopen'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'approve_timesheet_week', 'reopen_timesheet_week', and 'complete_timesheet_month', there's no indication of prerequisites, timing, or distinctions between completion and approval processes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new timesheet entry (log hours). Only one entry per employee/date/activity/project combo.
| Name | Required | Description | Default |
|---|---|---|---|
| employeeId | Yes | Employee ID | |
| projectId | Yes | Project ID | |
| activityId | Yes | Activity ID | |
| date | Yes | Date (yyyy-MM-dd) | |
| hours | Yes | Number of hours | |
| comment | No | Optional comment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: 'Only one entry per employee/date/activity/project combo', which indicates uniqueness constraints and potential error conditions. However, it doesn't mention other important aspects like authentication needs, rate limits, or what happens on duplicate attempts, leaving some gaps in 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 extremely concise with just two sentences that are front-loaded with the core purpose. Every word earns its place, with no wasted text, making it easy for an AI agent to parse quickly and understand the essential 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?
Given no annotations and no output schema, the description provides basic purpose and a constraint, but it lacks details on error handling, response format, or prerequisites. For a creation tool with 6 parameters, this is adequate but has clear gaps, making it minimally viable rather than fully 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?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description doesn't add any meaning beyond the schema, such as explaining parameter relationships or constraints beyond the uniqueness rule mentioned. This meets the baseline of 3 since 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?
The description clearly states the specific action ('Create a new timesheet entry') and the resource ('log hours'), distinguishing it from sibling tools like 'update_timesheet_entry' or 'delete_timesheet_entry' by specifying it's for creation only. The phrase 'Only one entry per employee/date/activity/project combo' adds unique behavioral context that further differentiates 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 implies usage context by stating 'Only one entry per employee/date/activity/project combo', which suggests when to use it (for creating new entries) and hints at constraints, but it doesn't explicitly mention when NOT to use it or name alternatives like 'update_timesheet_entry' for modifications. This provides some guidance but lacks explicit comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a timesheet entry.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Timesheet entry ID | |
| version | No | Version number for optimistic locking |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide 'destructiveHint: true', which already signals a destructive operation. The description adds no behavioral context beyond this, such as whether deletion is permanent, requires specific permissions, or has side effects (e.g., affecting approvals). It doesn't contradict annotations, but offers minimal additional value given the 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 is a single, direct sentence with no wasted words. It's front-loaded with the core action ('Delete'), making it easy to scan and understand quickly. Every word earns its place, achieving maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description is incomplete. It lacks context on what happens after deletion (e.g., success confirmation, error handling), doesn't reference sibling tools for related operations, and provides no usage examples or constraints. Given the complexity of a deletion operation, more guidance is needed.
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 has 100% description coverage, fully documenting both parameters ('id' and 'version'). The description adds no parameter semantics beyond what's in the schema, such as explaining the purpose of optimistic locking or where to find the ID. With high schema coverage, the baseline 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 verb ('Delete') and resource ('a timesheet entry'), making the purpose unambiguous. However, it doesn't distinguish this tool from sibling tools like 'update_timesheet_entry' or 'create_timesheet_entry' beyond the basic action, missing an opportunity to clarify its specific role in the timesheet management workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing entry ID), exclusions (e.g., not for bulk deletion), or related tools like 'search_timesheet_entries' for finding IDs or 'update_timesheet_entry' for modifications instead of deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the currently running time clock for an employee.
| Name | Required | Description | Default |
|---|---|---|---|
| employeeId | No | Employee ID (defaults to token owner) |
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 states what the tool does but lacks details on permissions required, error conditions (e.g., if no time clock is running), response format, or whether it's a read-only operation. This is a significant gap for a tool with no 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 is a single, clear sentence with no wasted words. It front-loads the key action and resource efficiently, making it easy to parse. Every part of the sentence contributes directly to understanding the tool's purpose.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'currently running time clock' entails, what data is returned, or how errors are handled. For a tool with no structured support, more context is needed to guide an AI agent effectively.
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 has 100% description coverage, with the 'employeeId' parameter documented as 'Employee ID (defaults to token owner)'. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without compensating value.
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 'currently running time clock for an employee', making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'start_time_clock' or 'stop_time_clock', but the focus on 'currently running' provides some distinction. No tautology or misleading elements are present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an employee with an active time clock, or compare it to related tools like 'get_timesheet_entry' or 'get_total_hours'. Usage is implied by the purpose 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.
Get a single outgoing invoice by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Invoice ID |
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 states it's a read operation ('Get'), but doesn't mention permissions needed, error handling, rate limits, or what the return format looks like (e.g., JSON structure). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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 (1 parameter, no output schema, no annotations), the description is minimal but adequate for basic understanding. However, it lacks context on return values, error cases, or how it fits with sibling tools, making it incomplete for optimal agent use without additional inference.
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 has 100% description coverage, with the 'id' parameter documented as 'Invoice ID'. The description adds no additional meaning beyond this, such as format examples or constraints. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the 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 verb ('Get') and resource ('a single outgoing invoice by ID'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_supplier_invoice' or 'search_invoices', which would require specifying it's for outgoing invoices versus supplier invoices or search operations.
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 such as 'search_invoices' or 'get_supplier_invoice'. The description implies usage for retrieving a specific invoice by ID but doesn't mention prerequisites, exclusions, or context for choosing this over other invoice-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recently used activities for a project.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | Project ID | |
| employeeId | No | Employee ID (defaults to token owner) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states the basic action without disclosing behavioral traits like read-only status, potential rate limits, authentication needs, or what 'recently used' entails (e.g., time frame, sorting). This is inadequate for a tool with no 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 is a single, efficient sentence with zero waste, front-loading the core action. It's appropriately sized for the tool's complexity.
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 no annotations, no output schema, and a read-like operation, the description is incomplete. It doesn't explain return values, error conditions, or behavioral context, making it insufficient for effective tool selection and invocation.
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 has 100% description coverage, documenting both parameters clearly. The description adds no additional meaning beyond implying a project context, so it meets the baseline of 3 without compensating for any gaps.
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 resource 'recently used activities for a project', making the purpose understandable. However, it doesn't distinguish from sibling tools like 'search_activities' or 'get_recent_projects', which could offer similar functionality, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'search_activities' or 'get_recent_projects'. It lacks context on prerequisites, exclusions, or specific scenarios, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recently used projects for timesheet entries.
| Name | Required | Description | Default |
|---|---|---|---|
| employeeId | No | Employee ID (defaults to token owner) |
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 'recently used projects' but doesn't specify what 'recent' means (e.g., time range, recency criteria), whether it's read-only, or any rate limits. This leaves significant gaps in understanding the tool's 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, 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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'recently used' entails, the return format, or how it differs from similar tools like 'search_projects', leaving the agent with insufficient context for effective use.
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 description coverage is 100%, with the parameter 'employeeId' well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for adequate but not exceptional coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('recently used projects for timesheet entries'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_projects' or 'get_timesheet_entry', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_projects' or other sibling tools. It lacks context about prerequisites, timing, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single supplier invoice by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Supplier invoice ID |
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 states it's a read operation ('Get'), implying non-destructive behavior, but doesn't cover other aspects like authentication requirements, rate limits, error handling, or what happens if the ID is invalid. For a tool with zero annotation coverage, this is a significant gap in 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 a single, direct sentence that efficiently conveys the core functionality without any fluff. It's front-loaded with the essential information, making it easy for an agent 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?
For a simple read tool with one parameter and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and output format. Given the low complexity and high schema coverage, it's functional but could be more informative to fully guide an agent.
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 input schema fully documents the single parameter 'id' as a number. The description adds no additional semantic context beyond implying the ID is for a supplier invoice, which is already covered by the schema. This meets the baseline score of 3 when schema coverage is high.
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 resource ('a single supplier invoice by ID'), making the purpose immediately understandable. It distinguishes from sibling tools like 'get_supplier_invoices_for_approval' and 'search_supplier_invoices' by specifying retrieval of a single invoice via ID, though it doesn't explicitly contrast with 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an invoice ID), exclusions, or compare it to similar tools like 'get_invoice' or 'search_supplier_invoices', leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get supplier invoices that are pending approval.
| Name | Required | Description | Default |
|---|---|---|---|
| searchText | No | Search text (department, employee, project) | |
| showAll | No | Show all invoices, not just own (default false) | |
| employeeId | No | Employee ID (defaults to logged in) | |
| from | No | Pagination offset | |
| count | No | Number of results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does ('Get supplier invoices that are pending approval') without mentioning permissions needed, whether it's read-only, what format results come in, pagination behavior, or any rate limits. For a tool with 5 parameters and no annotation coverage, this is insufficient.
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 that states exactly what the tool does with zero wasted words. It's appropriately sized and front-loaded with the core functionality.
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 tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how results are structured, or important behavioral aspects like permissions or pagination. The agent would struggle to use this tool effectively based on the description alone.
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 5 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 but doesn't provide extra value.
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 resource ('supplier invoices that are pending approval'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search_supplier_invoices' or 'get_supplier_invoice', which could cause confusion about when to use this specific tool versus 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 provides no guidance on when to use this tool versus alternatives like 'search_supplier_invoices' or 'get_supplier_invoice'. It doesn't mention prerequisites, context, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single timesheet entry by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Timesheet entry ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, what happens with invalid IDs, rate limits, or error conditions. The description lacks essential operational context for a tool that retrieves data by identifier.
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 perfectly concise - a single sentence that states exactly what the tool does without any unnecessary words. It's front-loaded with the core functionality and wastes no space on 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 data retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'timesheet entry' contains, what format the response takes, or what happens when retrieval fails. The agent needs more context to use this tool effectively in workflows.
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 has 100% description coverage, with the single parameter 'id' clearly documented as 'Timesheet entry ID'. The description adds no additional parameter information beyond what's in the schema, but since schema coverage is complete, this meets the baseline expectation for parameter documentation.
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 resource ('a single timesheet entry by ID'), making the purpose unambiguous. However, it doesn't explicitly distinguish this tool from sibling tools like 'search_timesheet_entries' or 'get_timesheet_month', which could cause confusion about when to use each specific retrieval method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_timesheet_entries' or 'get_timesheet_month'. There's no mention of prerequisites, context, or comparative use cases, leaving the agent to infer usage patterns from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get monthly timesheet status for employees.
| Name | Required | Description | Default |
|---|---|---|---|
| employeeIds | Yes | Employee ID(s), comma-separated | |
| monthYear | Yes | Month (e.g. '2026-02') |
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 states it 'gets' data, implying a read-only operation, but doesn't clarify if it requires authentication, returns paginated results, includes error handling, or provides details on the 'status' format (e.g., approved, pending). This leaves significant gaps for a tool with no 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 is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose, making it easy to parse quickly, which is ideal for conciseness.
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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'status' entails (e.g., hours worked, approval state), return format, or error conditions. Given the complexity of timesheet data and lack of structured output, more context is needed to help an agent use this tool effectively.
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 description coverage is 100%, with clear descriptions for both parameters (employeeIds as comma-separated IDs, monthYear as a date string). The description adds no additional semantic context beyond the schema, such as examples or constraints (e.g., valid employee ID formats). Given the high schema coverage, a baseline 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 verb ('Get') and resource ('monthly timesheet status for employees'), making the purpose understandable. However, it doesn't distinguish this from sibling tools like 'get_timesheet_entry' or 'search_timesheet_entries', which also retrieve timesheet data but with different scopes or filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_timesheet_entry' (single entry), 'search_timesheet_entries' (filtered entries), and 'get_total_hours' (aggregated hours), there's no indication that this tool is specifically for monthly status per employee, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get total hours registered for an employee in a date range.
| Name | Required | Description | Default |
|---|---|---|---|
| employeeId | No | Employee ID (defaults to token owner) | |
| startDate | No | Start date (yyyy-MM-dd, defaults to today) | |
| endDate | No | End date (yyyy-MM-dd, defaults to tomorrow) |
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 states the tool retrieves data ('Get'), implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, or what happens if no data is found (e.g., returns zero or an error). For a tool with no annotations, this is a significant gap in 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 a single, efficient sentence that front-loads the core functionality: 'Get total hours registered for an employee in a date range.' There is no wasted text, and it directly communicates the tool's purpose without unnecessary elaboration.
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 tool with no output schema and no annotations, the description is minimally adequate. It covers the basic purpose and parameters, but lacks details on behavioral traits (e.g., error handling) and usage guidelines. Given the tool's simplicity and high schema coverage, it's complete enough for basic use but could be improved with more 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?
The input schema has 100% description coverage, with clear defaults for all parameters (e.g., 'defaults to token owner' for employeeId). The description adds minimal value beyond the schema, as it only mentions 'employee in a date range' without detailing parameter roles or constraints. Given the high schema coverage, a baseline 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 tool's purpose: 'Get total hours registered for an employee in a date range.' It specifies the verb ('Get'), resource ('total hours'), and scope ('employee in a date range'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_timesheet_entry' or 'get_timesheet_month', which might also retrieve hour-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as whether the employee must exist or have timesheet data, or compare it to siblings like 'search_timesheet_entries' for more detailed queries. This lack of context leaves the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reject a supplier invoice. A comment is required.
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceId | Yes | Supplier invoice ID to reject | |
| comment | Yes | Rejection reason (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, indicating this is a mutation operation. The description adds that 'A comment is required,' which provides useful behavioral context about mandatory input. However, it doesn't elaborate on what rejection entails (e.g., status changes, notifications, reversibility) or any other behavioral traits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that communicate the core action and a key requirement. Every word serves a purpose, and it's front-loaded with the primary function. There's no wasted verbiage 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 destructive operation with no output schema, the description is minimal but covers the basic action. It lacks details on what rejection means in practice, potential side effects, or error conditions. Given the annotations cover destructiveness and schema covers parameters adequately, the description meets minimum viability but leaves gaps in operational 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?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds that 'A comment is required,' reinforcing the schema's required constraint but not providing additional semantic context about parameter usage, format expectations, or business rules beyond what the schema already states.
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 ('Reject') and resource ('supplier invoice'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'reject_supplier_invoices' (plural) or contrast with 'approve_supplier_invoice', leaving some ambiguity about when to use this specific singular rejection 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?
The description provides no guidance on when to use this tool versus alternatives like 'reject_supplier_invoices' (plural) or 'approve_supplier_invoice'. It mentions a comment requirement, which is a prerequisite rather than usage context. There's no indication of appropriate scenarios or constraints for rejection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reject multiple supplier invoices at once. A comment is required.
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceIds | Yes | Comma-separated invoice IDs | |
| comment | Yes | Rejection reason (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true, indicating this is a destructive operation. The description adds that it handles 'multiple invoices at once' (batch behavior) and requires a comment, which are useful behavioral details beyond annotations. However, it doesn't cover other aspects like permissions, side effects, or error handling.
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, front-loaded with the main action and scope, followed by a key requirement. Every word adds value with zero waste, making it highly efficient and easy 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?
For a destructive tool with two parameters and no output schema, the description covers the batch nature and comment requirement but lacks details on outcomes (e.g., what happens after rejection), error cases, or integration with sibling tools. It's adequate but has clear gaps in completeness.
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 clear parameter descriptions. The description adds that 'A comment is required,' reinforcing the schema's required field, but doesn't provide additional semantic context (e.g., comment format or invoice ID specifics). Baseline 3 is appropriate as the schema handles most documentation.
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 ('reject') and resource ('supplier invoices'), and specifies it handles 'multiple' invoices at once. It distinguishes from the sibling 'reject_supplier_invoice' (singular) by indicating batch processing. However, it doesn't explicitly differentiate from other rejection-related tools beyond this scope.
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 for rejecting invoices with a required comment, but doesn't specify when to use this vs. the singular 'reject_supplier_invoice' or other invoice-related tools. No explicit alternatives, prerequisites, or exclusions are mentioned, leaving the context somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reopen a completed/approved timesheet month.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Timesheet month ID | |
| employeeIds | No | Employee ID(s), comma-separated | |
| monthYear | No | Month (e.g. '2026-02') |
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 implies a mutation (reopening) but doesn't specify critical details: whether this requires special permissions, if it's reversible, what happens to associated data (e.g., approvals or entries), or any rate limits. The description is minimal and lacks behavioral context beyond the basic action.
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, direct sentence that efficiently conveys the core action without any fluff. It's front-loaded with the verb and resource, making it easy to parse. Every word serves a purpose, achieving maximum clarity with minimal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain the outcome (e.g., what 'reopened' means functionally), error conditions, or side effects. For a tool that alters system state, more context is needed to ensure safe and correct usage.
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 description coverage is 100%, so the schema already documents all three parameters (id, employeeIds, monthYear) with clear descriptions. The tool description adds no additional parameter information beyond what's in the schema, such as how parameters interact or which are required. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reopen') and the resource ('a completed/approved timesheet month'), making the purpose immediately understandable. It distinguishes from sibling tools like 'reopen_timesheet_week' by specifying 'month' instead of 'week', but doesn't explicitly differentiate from other month-related tools like 'approve_timesheet_month' or 'complete_timesheet_month' beyond the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that the timesheet month must already be completed/approved), nor does it compare with related tools like 'reopen_timesheet_week' or explain when reopening is appropriate versus other actions like updating entries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reopen a completed/approved timesheet week.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Timesheet week ID | |
| employeeId | No | Employee ID | |
| weekYear | No | ISO week-year (e.g. '2026-07') |
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 indicates a mutation action ('Reopen') but lacks details on permissions required, whether the operation is reversible, potential side effects, or error conditions. This is inadequate for a mutation 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 is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and appropriately sized for the task.
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 complexity as a mutation operation, the lack of annotations and output schema, and incomplete behavioral details in the description, the description is insufficient. It does not cover critical aspects like return values, error handling, or operational constraints, leaving significant gaps for an AI agent.
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 description coverage is 100%, so the schema already documents all three parameters (id, employeeId, weekYear). The description does not add any additional meaning or context beyond what the schema provides, such as how these parameters interact or which are required, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Reopen' and the resource 'a completed/approved timesheet week,' making the purpose explicit. However, it does not distinguish this tool from its sibling 'reopen_timesheet_month,' which performs a similar action on a different resource, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the target state ('completed/approved timesheet week'), but it does not provide explicit guidance on when to use this tool versus alternatives like 'reopen_timesheet_month' or other timesheet-related tools. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for activities (e.g. development, meetings, vacation). Use this to find activity IDs for logging hours.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Search by activity name (partial match) | |
| number | No | Search by activity number (exact match) | |
| isProjectActivity | No | Filter to project activities only | |
| isGeneral | No | Filter to general activities only | |
| isInactive | No | Filter by inactive status (default: show active) | |
| from | No | Pagination offset | |
| count | No | Number of results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the search purpose and example activity types, but doesn't describe important behaviors like whether this is a read-only operation, what format results return, if there are rate limits, authentication requirements, or pagination behavior beyond the schema parameters. The description adds minimal behavioral context beyond the basic purpose.
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 extremely concise with just two sentences that both earn their place. The first sentence states the purpose with helpful examples, and the second sentence provides the usage context. There's zero wasted text and it's front-loaded with the core functionality.
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 search tool with 7 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate basic context but lacks important behavioral information. It explains the 'why' (finding IDs for logging hours) but doesn't address result format, pagination behavior, or operational constraints that would be helpful for an AI agent.
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 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the 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 tool searches for activities and provides the purpose (to find activity IDs for logging hours). It uses specific verbs ('search for', 'find') and identifies the resource ('activities'), but doesn't explicitly differentiate from sibling tools like 'get_recent_activities' or 'search_projects'.
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 ('to find activity IDs for logging hours'), suggesting this tool is preparatory for logging operations. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_recent_activities' or other search tools, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search outgoing (customer) invoices by date range.
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceDateFrom | Yes | From date inclusive (yyyy-MM-dd) | |
| invoiceDateTo | Yes | To date exclusive (yyyy-MM-dd) | |
| invoiceNumber | No | Filter by invoice number | |
| customerId | No | Filter by customer ID | |
| from | No | Pagination offset | |
| count | No | Number of results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'search' and 'outgoing (customer) invoices' but lacks critical details: whether this is read-only, if it requires authentication, pagination behavior (implied by parameters but not explained), rate limits, or what the response format looks like. This is inadequate for a search tool with 6 parameters.
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 immediately conveys the core functionality without any wasted words. It's appropriately sized and front-loaded with essential 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 search tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (read-only status, authentication needs), usage guidance versus siblings, and details about return values. The high parameter count and absence of structured metadata require more comprehensive description coverage.
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 6 parameters thoroughly. The description adds minimal value by implying date range filtering but provides no additional semantic context beyond what's in the schema. Baseline 3 is appropriate when 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?
The description clearly states the action ('Search') and resource ('outgoing (customer) invoices by date range'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_supplier_invoices' or 'get_invoice', which would require 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 no guidance on when to use this tool versus alternatives like 'get_invoice' (for single invoices) or 'search_supplier_invoices' (for supplier invoices). It mentions date range filtering but offers no context about use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for projects by name or other filters. Use this to find project IDs for logging hours.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Search by project name (partial match) | |
| number | No | Search by project number (exact match) | |
| employeeInProjectId | No | Filter by employee ID(s) assigned to project | |
| projectManagerId | No | Filter by project manager ID(s) | |
| isClosed | No | Filter by closed status | |
| from | No | Pagination offset | |
| count | No | Number of results |
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 mentions searching by 'name or other filters' and the purpose of finding IDs for logging hours, but it lacks details on behavioral traits such as pagination behavior (implied by 'from' and 'count' parameters but not explained), rate limits, authentication needs, or what the output looks like. For a search tool with 7 parameters, this is insufficient.
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 and well-structured with two sentences: the first states the purpose, and the second provides usage context. Every sentence earns its place, and it's front-loaded with the core functionality. No wasted words or 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?
Given the complexity (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return format, pagination behavior, or error handling. While the schema covers parameters, the description lacks behavioral context needed for effective tool use, especially for a search operation with multiple filters.
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 parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'name or other filters' and the high-level goal of finding project IDs. It doesn't provide additional syntax, format details, or usage examples for parameters. Baseline 3 is appropriate as 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?
The description clearly states the tool's purpose: 'Search for projects by name or other filters.' It specifies the resource (projects) and the action (search). However, it doesn't explicitly distinguish this tool from sibling tools like 'search_activities' or 'search_invoices' beyond mentioning projects.
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 usage context: 'Use this to find project IDs for logging hours.' This implies when to use it (for logging hours), but it doesn't offer explicit guidance on when to choose this tool over alternatives like 'get_recent_projects' or other search tools. No exclusions or clear alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search incoming (supplier) invoices by date range.
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceDateFrom | Yes | From date inclusive (yyyy-MM-dd) | |
| invoiceDateTo | Yes | To date exclusive (yyyy-MM-dd) | |
| invoiceNumber | No | Filter by invoice number | |
| supplierId | No | Filter by supplier ID | |
| from | No | Pagination offset | |
| count | No | Number of results |
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 states the tool searches by date range but doesn't mention other behaviors: whether it's read-only (implied by 'search'), what permissions are required, if there are rate limits, the format of results (e.g., list of invoices), or pagination details (though parameters hint at it). For a search tool with zero annotation coverage, this leaves significant gaps in understanding how it operates.
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: 'Search incoming (supplier) invoices by date range.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a search tool. Every part of the sentence contributes to understanding the tool's function.
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 complexity (6 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavioral traits, usage context, and result format. Without annotations or output schema, the agent must rely heavily on the input schema and trial-and-error. It's complete enough to avoid being useless but has clear gaps for effective tool selection.
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 6 parameters with clear descriptions (e.g., date formats, filtering options, pagination). The description adds minimal value beyond the schema—it mentions date range filtering but doesn't explain parameter interactions or provide additional context. This meets the baseline of 3 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?
The description clearly states the tool's purpose: 'Search incoming (supplier) invoices by date range.' It specifies the verb ('search'), resource ('incoming (supplier) invoices'), and scope ('by date range'). However, it doesn't explicitly differentiate from sibling tools like 'search_invoices' or 'get_supplier_invoice', which could cause confusion about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_invoices' (which might search all invoices) or 'get_supplier_invoice' (which might retrieve a single invoice), nor does it specify prerequisites or exclusions. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search timesheet entries for a date range. Returns hours logged by employees.
| Name | Required | Description | Default |
|---|---|---|---|
| dateFrom | Yes | From date inclusive (yyyy-MM-dd) | |
| dateTo | Yes | To date exclusive (yyyy-MM-dd) | |
| employeeId | No | Filter by employee ID(s), comma-separated | |
| projectId | No | Filter by project ID(s), comma-separated | |
| activityId | No | Filter by activity ID(s), comma-separated | |
| comment | No | Filter by comment text | |
| from | No | Pagination offset (default 0) | |
| count | No | Number of results (default 1000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions the date range scope and return type. It doesn't disclose important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior beyond the schema parameters, or what format the hours data returns in.
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 extremely concise with just two sentences that directly state the tool's purpose and return value. Every word earns its place with zero redundancy or unnecessary elaboration.
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 search tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the search logic, result format, error conditions, or how parameters interact. The agent would struggle to use this tool effectively without trial and error.
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 8 parameters thoroughly. The description adds minimal value beyond the schema, only implying date-range filtering without providing additional context about parameter interactions or search logic.
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 timesheet entries for a date range and returns hours logged by employees, providing specific verb ('search') and resource ('timesheet entries'). However, it doesn't distinguish itself from sibling tools like 'search_timesheet_weeks' or 'get_timesheet_entry', which could cause confusion about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_timesheet_weeks', 'get_timesheet_entry', or 'get_total_hours'. With multiple timesheet-related tools available, the absence of usage context leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search weekly timesheet status.
| Name | Required | Description | Default |
|---|---|---|---|
| employeeIds | No | Employee ID(s), comma-separated | |
| weekYear | No | ISO week-year (e.g. '2026-07') | |
| from | No | Pagination offset | |
| count | No | Number of results |
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 only states the action ('search') without detailing behavioral traits like whether it's read-only, requires authentication, has rate limits, or what the output format might be. For a search tool with zero annotation coverage, this is a significant gap in 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 a single, concise sentence with no wasted words. It is front-loaded and efficiently conveys the core action, though it could be more informative. The brevity is appropriate but borders on under-specification.
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 complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, usage context, and output expectations, making it insufficient for an agent to fully understand how to invoke and interpret results from this 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?
The input schema has 100% description coverage, so the schema already documents all parameters (employeeIds, weekYear, from, count). The description adds no additional meaning beyond what the schema provides, such as explaining parameter interactions or default behaviors. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose as 'Search weekly timesheet status,' which is clear but vague. It specifies the verb 'search' and resource 'weekly timesheet status,' but lacks specificity about what 'status' entails or how it differs from sibling tools like 'search_timesheet_entries' or 'get_timesheet_month.' This makes it minimally adequate but not distinct.
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. The description does not mention any context, prerequisites, or exclusions, such as how it compares to other search or get tools in the sibling list. This leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a time clock (timer) for tracking hours in real-time.
| Name | Required | Description | Default |
|---|---|---|---|
| activityId | Yes | Activity ID | |
| projectId | No | Project ID | |
| employeeId | No | Employee ID (defaults to token owner) | |
| date | No | Date (defaults to today) | |
| comment | No | Optional comment |
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 starting a timer but doesn't cover critical aspects like whether this is a mutation (likely yes), what happens if a timer is already running, permissions required, or how the timer interacts with other time-tracking tools. This leaves significant gaps for an agent.
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 directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, 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?
Given the complexity of starting a timer (a mutation with no annotations or output schema), the description is incomplete. It lacks details on behavior, error conditions, relationships with sibling tools like 'stop_time_clock', and what the tool returns. This leaves the agent with insufficient context for reliable use.
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 has 100% description coverage, so the schema already documents all parameters well. The description adds no additional parameter information beyond implying a timer is started, which aligns with the schema but doesn't enhance it. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('start') and resource ('time clock/timer') with the purpose 'for tracking hours in real-time', making it specific and understandable. However, it doesn't explicitly differentiate from its sibling 'stop_time_clock' or other time-related tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_timesheet_entry' or 'stop_time_clock', nor does it mention prerequisites or context. It merely states what the tool does without indicating usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running time clock.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Time clock ID | |
| comment | No | Optional comment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action but doesn't reveal whether stopping is reversible, what permissions are needed, if it triggers notifications, or what happens to the stopped time data. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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 with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for the tool's complexity.
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 annotations and no output schema, the description is incomplete. It doesn't explain what happens after stopping (e.g., whether hours are saved, if status changes), nor does it cover error conditions or dependencies. Given the lack of structured data, more behavioral context is needed.
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 (id and comment). The description doesn't add any parameter-specific context beyond what's in the schema, such as explaining what a 'time clock ID' represents or when a comment might be useful. Baseline 3 is appropriate when 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?
The description clearly states the action ('Stop') and resource ('a running time clock'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'start_time_clock' beyond the opposite action, but the verb+resource combination is specific enough for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a time clock must be running), nor does it reference related tools like 'get_current_time_clock' to check status first. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing timesheet entry. Fields not set will be nulled.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Timesheet entry ID | |
| version | Yes | Current version number (for optimistic locking) | |
| employeeId | Yes | Employee ID | |
| projectId | Yes | Project ID | |
| activityId | Yes | Activity ID | |
| date | Yes | Date (yyyy-MM-dd) | |
| hours | Yes | Number of hours | |
| comment | No | Optional comment |
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 that 'Fields not set will be nulled,' which is a critical behavioral trait (partial updates lead to nullification), but it doesn't cover other important aspects like authentication needs, error handling, or whether the operation is idempotent. This leaves significant gaps 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 extremely concise—just one sentence—and front-loaded with the core purpose. Every word earns its place, with no redundant or verbose language, making it efficient and easy 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?
Given the complexity of an update operation with 8 parameters and no annotations or output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, permissions), response format, or error conditions, which are crucial for safe and effective tool invocation in this 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?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional semantic information about parameters beyond what's in the schema, such as explaining interactions between fields. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('existing timesheet entry'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'create_timesheet_entry' or 'delete_timesheet_entry' beyond the verb, missing an opportunity for clearer distinction.
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. For example, it doesn't mention prerequisites like needing an existing entry ID or when to choose this over 'create_timesheet_entry' for modifications. The description lacks context about usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the currently authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get information' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what happens if no user is authenticated. The description is minimal and lacks important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core functionality and wastes no space on redundant information. Perfectly 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?
For a zero-parameter tool with no output schema, the description provides the basic purpose but lacks important context. It doesn't specify what information is returned, authentication requirements, or how this differs from other user-related tools in the sibling list. While adequate for the simplest case, more completeness would help the agent understand the tool's role in the broader system.
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 schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is appropriate for zero-parameter tools with complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get information') and target ('currently authenticated user'), making the purpose immediately understandable. However, it doesn't specify what type of information is returned (e.g., name, email, permissions) or differentiate from potential sibling tools like 'get_current_time_clock' that might also return user-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include various user-related operations (time tracking, timesheets, invoices), there's no indication whether this is for authentication verification, profile retrieval, or permission checking. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but there is some overlap between approve/reject supplier invoices (single vs. multiple) and timesheet month/week operations, which could cause minor confusion. The descriptions clarify the differences, so misselection is unlikely.
All tools follow a consistent verb_noun naming pattern (e.g., approve_supplier_invoice, get_timesheet_entry, search_activities). There are no deviations in style or convention, making the set predictable and readable.
With 31 tools, the count is borderline high for a timesheet and invoicing server, potentially feeling heavy. However, it covers multiple domains (timesheets, invoices, time clocks), so it's not extreme but may overwhelm agents.
The toolset provides comprehensive coverage for timesheet management (CRUD, approval, completion, reopening), supplier invoice handling (approval, rejection, search), and time clock operations. No obvious gaps exist for the stated purposes.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage Avaza projects, tasks, timesheets, expenses, invoices, and scheduling from AI assistants.
Manage projects, tasks, time tracking, and team collaboration through natural language.
Log, query, and edit expenses, budgets, and accounts in Ledgy from any MCP-compatible AI assistant.
Compliance infrastructure API connecting AI agents to Norwegian government systems (Altinn, BRREG).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/adriantr/tripletex-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
