A
licenseNot graded
qualityD
maintenanceAn MCP server for integrating AI models with client applications, allowing for structured interactions with APIs using command-line arguments for authentication and configuration.
2,013
MIT
ServiceTitan MCP Server
by JordanDalton
Integrates with ServiceTitan's API, allowing access to the ServiceTitan platform for field service management operations. The MCP server requires ServiceTitan credentials (client ID, client secret, app key, and tenant ID) to function.
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., "@ServiceTitan MCP Serverget recent service calls for customer ID 12345"
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.
ServiceTitan MCP Server
(Please test)
To build the MCP server, run:
npm install && npm run buildThis will compile the typescript files and produce a build directory plus it will output the json you can copy/paste into your MCP client (Claude Desktop, Windsurf, Cursor, etc.)
If all things go well, this will produce an output similar to this:
{
"mcpServers": {
"my-mcp": {
"command": "node",
"args": [
"<thePathToYour>/build/index.js"
],
"env": [
{
"SERVICE_TITAN_CLIENT_ID": "<REPLACE>"
},
{
"SERVICE_TITAN_CLIENT_SECRET": "<REPLACE>"
},
{
"SERVICE_TITAN_APP_KEY": "<REPLACE>"
},
{
"SERVICE_TITAN_TENANT_ID": "<REPLACE>"
}
]
}
}
}If you have found value in this service please share it on social media. You can tag me @jordandalton on X, or jdcarnivore on Reddit.
Available Tools
454 toolsactivities_controllers_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. The activity ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
activities_controllers_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by specified fields | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
activity_categories_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The activity category ID | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
activitycategories_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
activity_codes_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. ID of the payroll activity code | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
activity_codes_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
activity_types_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. The activity types ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
activity_types_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
adjustments_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| adjustmentTypes | No | Filter by a collection of adjustment types | |
| batchId | No | Format - int64. BatchId filter | |
| businessUnitIds | No | Filter by a collection of business unit Ids | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customFields.Fields | No | Collection of custom field pairs (name, value) to filter by | |
| customFields.Operator | No | Can be "Or" or "And" Values: [And, Or] | |
| dateBefore | No | Format - date-time (as date-time in RFC3339). Return adjustments with date before certain date/time | |
| dateOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return adjustments with date on or after certain date/time | |
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| externalDataKey | No | Performs lookup by external data key, 'externalDataValues' must also be provided. | |
| externalDataValues | No | Performs lookup by external data values (maximum 50), 'externalDataKey' must also be provided. | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| inventoryLocationIds | No | Filter by a collection of inventory location Ids | |
| invoiceIds | No | Filter by a collection of invoice Ids | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| number | No | Number filter | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| referenceNumber | No | Reference number filter | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| syncStatuses | No | Filter by a collection of sync statues | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
adjustments_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Adjustment Id | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adjustments_UpdateCustomFieldsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| customFields | Yes | Custom fields to update | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ApCredits_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by specified fields | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ap_credits_markasexportedD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ap_payments_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by specified fields | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ApPayments_MarkAsExportedD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AppointmentAssignments_AssignTechniciansD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
appointment_assignments_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| appointmentIds | No | Return appointment assignments for one or more appointments | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| jobId | No | Format - int64. Return appointment assignments for a single job | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, CreatedOn, ModifiedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
appointment_assignments_unassign_techniciansD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
appointments_addD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| appointmentNumber | Yes | Appointment Number | |
| arrivalWindowEnd | No | Arrival Window End time | |
| arrivalWindowStart | No | Arrival Window Start time | |
| createdById | Yes | Created By ID | |
| customerId | Yes | Customer ID | |
| end | Yes | End time | |
| isConfirmed | No | Is Confirmed | |
| jobId | Yes | Job ID | |
| specialInstructions | No | Special Instructions | |
| start | Yes | Start time | |
| status | No | Status | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
appointments_confirmD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
appointments_deleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
appointments_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The appointment ID (int64) | |
| tenant | Yes | The tenant ID (int64) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
appointments_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return appointments created before a certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return appointments created on or after a certain date/time (in UTC) | |
| customerId | No | Format - int64. Return appointments for the specified Customer | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| jobId | No | Format - int64. Return all appointments for this job | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return appointments modified before a certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return appointments modified on or after a certain date/time (in UTC) | |
| number | No | Return all appointments with this appointment number | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| projectId | No | Format - int64. Return all appointments for jobs that are part of this project | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| startsBefore | No | Format - date-time (as date-time in RFC3339). Return appointments that start before the specified date/time (in UTC) | |
| startsOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return appointments that start on or after the specified date/time (in UTC) | |
| status | No | Return items with specified status AppointmentStatus Values: [Scheduled, Dispatched, Working, Hold, Done, Canceled] | |
| technicianId | No | Format - int64. Return appointments this technician is assigned to | |
| tenant | Yes | Format - int64. Tenant ID | |
| unused | No | Return appointments that are unused |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
appointments_holdD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
appointments_removeconfirmationD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
appointments_remove_holdD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The appointment ID (int64) | |
| tenant | Yes | The tenant ID (int64) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
appointments_rescheduleD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Request body (optional) | |
| id | Yes | The appointment ID (int64) | |
| tenant | Yes | The tenant ID (int64) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
appointments_update_special_instructionsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| specialInstructions | Yes | Special instructions to update | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ArrivalWindows_ActivatedD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arrival_windows_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | Yes | Active status | |
| businessUnitIds | Yes | Business Unit IDs | |
| duration | Yes | Duration | |
| start | Yes | Start time | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ArrivalWindows_GetD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arrival_windows_get_configurationD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arrival_windows_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arrival_windows_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | ||
| businessUnitIds | No | ||
| duration | No | ||
| id | Yes | Format - int64. | |
| start | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arrival_windows_updated_configurationD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Request Body | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attributed_leads_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| fromUtc | Yes | Format - date-time (as date-time in RFC3339). Gets or sets the start date and time in UTC for the filtering period. | |
| includeTotal | No | Whether total count should be returned | |
| leadType | No | Gets or sets the type of lead for filtering purposes. Possible values are: LeadType.Call, LeadType.WebBooking, LeadType.WebLeadForm, LeadType.ManualJob. If null, data for all lead types is returned. | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID | |
| toUtc | Yes | Format - date-time (as date-time in RFC3339). Gets or sets the end date and time in UTC for the filtering period. |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
BookingProviderTags_CreateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
booking_provider_tags_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
booking_provider_tags_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| name | No | Name of the booking provider tag | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
booking_provider_tags_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | Description | |
| id | Yes | Format - int64. | |
| tagName | No | Tag Name | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bookings_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Request body | |
| booking_provider | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bookings_create_contactD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| booking_provider | Yes | Format - int64. | |
| id | Yes | Format - int64. | |
| memo | No | Contact memo | |
| tenant | Yes | Format - int64. Tenant ID | |
| type | Yes | Contact type | |
| value | Yes | Contact value |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bookings_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bookings_getcontactlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The booking ID (int64) | |
| includeTotal | No | Whether total count should be returned | |
| page | No | The logical number of page to return, starting from 1 (int32) | |
| pageSize | No | How many records to return (50 by default) (int32) | |
| tenant | Yes | The tenant ID (int64) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bookings_get_contact_list2D
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| booking_provider | Yes | Format - int64. | |
| id | Yes | Format - int64. | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bookings_get_for_providerD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| booking_provider | Yes | Format - int64. | |
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bookings_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| externalId | No | Filters by booking's external ID | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bookings_GetList2D
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| booking_provider | Yes | Format - int64. | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| externalId | No | Filters by booking's external ID | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bookings_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| booking_provider | Yes | Format - int64. | |
| id | Yes | Format - int64. | |
| payload | No | JSON payload for the update | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bookings_updatebookingcontactD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| booking_provider | Yes | Format - int64. | |
| contactId | Yes | Format - int64. | |
| id | Yes | Format - int64. | |
| memo | No | Optional memo for the contact | |
| tenant | Yes | Format - int64. Tenant ID | |
| type | Yes | Contact type (e.g., Phone) | |
| value | Yes | Contact value (e.g., phone number) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bulk_tags_add_tagsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | Array of tags to add | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bulk_tags_remove_tagsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
BusinessHour_CreateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| saturday | No | ||
| sunday | No | ||
| tenant | Yes | Format - int64. Tenant ID | |
| weekdays | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
business_hour_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
business_units_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| externalDataApplicationGuid | No | Format - guid. | |
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
business_units_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| name | No | Filters records by name (case-insensitive 'contains' operation) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
business_units_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. BusinessUnit Id | |
| payload | No | Payload for the update | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
call_reasons_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calls_callsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| agentExternalId | No | Format - int64. Agent external ID (number) | |
| agentId | No | Format - int64. Agent ID (number) | |
| agentIsExternal | No | Is agent external flag (boolean) | |
| agentName | No | Agent name (string) | |
| callerPhoneNumber | No | The caller's phone number (string) | |
| campaignId | No | Format - int64. Campaign ID | |
| createdAfter | No | Format - date-time (as date-time in RFC3339). Return items created after certain date/time (in UTC) | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| minDuration | No | Format - int32. Minimum call duration (number of seconds) | |
| modifiedAfter | No | Format - date-time (as date-time in RFC3339). Return items modified after certain date/time (in UTC) | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| phoneNumberCalled | No | The phone number that was called (string) | |
| sort | No | The Sorting field, possible values: Id, CreatedOn, ModifiedOn. The Sorting is ascending by default, add the '-' character to use descending (for example -Id) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calls_get_callsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| activeOnly | No | ||
| agentExternalId | No | Format - int64. Agent external ID (number) | |
| agentId | No | Format - int64. Agent ID (number) | |
| agentIsExternal | No | Is agent external flag (boolean) | |
| agentName | No | Agent name (string) | |
| campaignId | No | Format - int64. Campaign ID | |
| createdAfter | No | Format - date-time (as date-time in RFC3339). | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Created on or after a certain date/time (as date-time in RFC3339), inclusive | |
| ids | No | ||
| minDuration | No | Format - int32. Minimum call duration (number) | |
| modifiedAfter | No | Format - date-time (as date-time in RFC3339). Modified after a certain date/time (as date-time in RFC3339), not inclusive | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Modified before a certain date/time (as date-time in RFC3339), not inclusive | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Modified on or after a certain date/time (as date-time in RFC3339), inclusive | |
| orderBy | No | Sorting (string with possible values Id (default), createdOn, or modifiedOn) | |
| orderByDirection | No | Sorting direction (string with possible values asc (default) or desc) | |
| page | No | Format - int32. | |
| pageSize | No | Format - int32. | |
| phoneNumberCalled | No | The phone number that was called (string) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calls_getdetailsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Id of the call. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calls_getrecordingD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Id of the call. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calls_get_voice_mailD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Id of the call. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calls_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Request body | |
| id | Yes | Format - int64. Id of updating call. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaign_categories_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaign_categories_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaign_categories_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, CreatedOn, Name | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaign_categories_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaign_costs_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | Yes | Campaign ID | |
| dailyCost | Yes | Daily Cost | |
| month | Yes | Month | |
| tenant | Yes | Format - int64. Tenant ID | |
| year | Yes | Year |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaign_costs_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaign_costs_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | No | Format - int64. Campaign ID | |
| includeTotal | No | Whether total count should be returned | |
| month | No | Format - int32. Month | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Date (Year + Month) | |
| tenant | Yes | Format - int64. Tenant ID | |
| year | No | Format - int32. Year |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaign_costs_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| payload | No | The payload to update costs | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaigns_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| businessUnit | No | Business unit | |
| campaignPhoneNumbers | No | List of campaign phone numbers | |
| medium | No | Campaign medium | |
| name | Yes | Campaign name | |
| otherMedium | No | Other campaign medium | |
| otherSource | No | Other campaign source | |
| source | No | Campaign source | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaigns_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaigns_getcostsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| includeTotal | No | Whether total count should be returned | |
| month | No | Format - int32. | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Date (Year + Month) | |
| tenant | Yes | Format - int64. Tenant ID | |
| year | No | Format - int32. |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaigns_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| campaignPhoneNumber | No | Filters campaigns by phone number (as string). | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| name | No | Filters records by name (case-insensitive 'contains' operation) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: '?sort=+FieldName' for ascending order, '?sort=-FieldName' for descending order. Available fields are: Id, Name, CreatedOn, ModifiedOn | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaigns_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Is Campaign Active? | |
| businessUnit | No | Business Unit | |
| campaignPhoneNumbers | No | Campaign Phone Numbers | |
| id | Yes | Format - int64. Campaign ID | |
| medium | No | Campaign Medium | |
| name | No | Campaign Name | |
| otherMedium | No | Other Campaign Medium | |
| otherSource | No | Other Campaign Source | |
| source | No | Campaign Source | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CapacityAwarenessWarning_GetD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
capacity_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
categories_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
categories_deleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Id of the SKU you are deleting | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
categories_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. The id of the service you are requesting | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
categories_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| categoryType | No | Category type Values: [Services, Materials] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Name. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
categories_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Request body (optional) | |
| id | Yes | Format - int64. Unique id for the SKU is modified | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
client_side_data_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
client_specific_pricing_get_all_rate_sheetsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Values: [True, Any, False] | |
| ids | No | List of ids | |
| includeTotal | No | Include total count | |
| page | No | Page number | |
| pageSize | No | Page size | |
| searchTerm | No | Search term | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
client_specific_pricing_update_rate_sheetD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | The payload to update the rate sheet with | |
| rateSheetId | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contact_methods_create_contact_methodD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | The contact UUID | |
| memo | No | The description of contact method | |
| tenant | Yes | Tenant ID | |
| type | Yes | The type of contact method | |
| value | Yes | The value of contact method |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contact_methods_DeleteContactMethodD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | Format - guid. | |
| contactMethodId | Yes | Format - guid. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contact_methods_get_contact_methodD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | The contact UUID | |
| contactMethodId | Yes | The contact method UUID | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ContactMethods_GetContactMethodsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | Format - guid. | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| referenceId | No | Filters by reference ID | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID | |
| type | No | Filters by contact method type | |
| value | No | Filters by contact method value |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contact_methods_update_contact_methodD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | Format - guid. | |
| contactMethodId | Yes | Format - guid. | |
| payload | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contact_methods_upsert_contact_methodD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | The contact UUID | |
| contactMethodId | Yes | The contact method UUID | |
| payload | No | Payload for updating contact method | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contacts_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBy | No | Created By | |
| createdOn | No | Created On | |
| id | No | Contact ID | |
| isArchived | No | Is Archived | |
| modifiedBy | No | Modified By | |
| modifiedOn | No | Modified On | |
| name | No | Contact Name | |
| referenceId | No | Reference ID | |
| tenant | Yes | Format - int64. Tenant ID | |
| title | No | Contact Title |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contacts_create_contact_relationshipD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | Format - guid. Contact Id | |
| relatedEntityId | Yes | Format - int64. Related Entity ID | |
| tenant | Yes | Format - int64. Tenant ID | |
| typeSlug | Yes | Relationship type slug: customer, location, booking |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contacts_deletecontactD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - guid. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contacts_deletecontactrelationshipD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | Format - guid. Contact Id | |
| relatedEntityId | Yes | Format - int64. Related Entity ID | |
| tenant | Yes | Format - int64. Tenant ID | |
| typeSlug | Yes | Relationship type: customer, location, booking |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contacts_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - guid. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contacts_get_by_relationship_idD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| isArchived | No | Filters by contact archive status | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| name | No | Filters by contact name | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| referenceId | No | Filters by external reference ID | |
| relationshipId | Yes | Format - int64. | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID | |
| title | No | Filters by contact title |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contacts_getcontactrelationship_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | Format - guid. | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| relatedEntityId | No | Format - int64. Filters by related entity id | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: ID, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID | |
| typeName | No | Relationship type name: Customer, Location, Booking | |
| typeSlug | No | Relationship type slug: customer, location, booking |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contacts_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| isArchived | No | Filters by contact archive status | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| name | No | Filters by contact name | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| referenceId | No | Filters by external reference ID | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID | |
| title | No | Filters by contact title |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contacts_replaceD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Request Body | |
| id | Yes | Format - guid. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contacts_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - guid. | |
| isArchived | No | Indicates if the contact is archived | |
| name | No | Name of the contact | |
| referenceId | No | Reference ID for the contact | |
| tenant | Yes | Format - int64. Tenant ID | |
| title | No | Title of the contact |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customer_memberships_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | Request Payload | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customer_memberships_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Customer membership ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customer_memberships_get_custom_fieldsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by specified fields | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customer_memberships_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| billingFrequency | No | Filters by membership billing frequency Values: [OneTime, Monthly, EveryOtherMonth, Quarterly, BiAnnual, Annual] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customerIds | No | Filters by customer IDs | |
| duration | No | Format - int32. Filters by membership duration (in months); use null for ongoing memberships | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| status | No | Filters by membership status Values: [Active, Suspended, Expired, Canceled, Deleted] | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customer_memberships_get_status_changesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Customer membership ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CustomerMemberships_UpdateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Customer membership ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Customer address | |
| balance | No | Customer balance | |
| contacts | No | Customer contacts | |
| customFields | No | Custom fields | |
| doNotMail | No | Do not mail flag | |
| doNotService | No | Do not service flag | |
| externalData | No | External data | |
| locations | No | Customer locations | |
| name | Yes | Customer name | |
| tagTypeIds | No | Tag type IDs | |
| tenant | Yes | Format - int64. Tenant ID | |
| type | No | Customer type |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_createcontactD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| memo | No | Contact Memo | |
| phoneSettings | No | Phone Settings | |
| tenant | Yes | Format - int64. Tenant ID | |
| type | No | Contact Type | |
| value | No | Contact Value |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_create_noteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdById | No | The ID of the user who created the note | |
| id | Yes | Format - int64. | |
| isPinned | No | Whether the note is pinned | |
| tenant | Yes | Format - int64. Tenant ID | |
| text | Yes | The note text |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_create_tagD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tagTypeId | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_delete_contactD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | Format - int64. | |
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_delete_noteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| noteId | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_delete_tagD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tagTypeId | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_get_contact_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_get_custom_field_typesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Returns customer records by active status (only active items will be returned by default). Values: [True, Any, False] | |
| city | No | Returns customer records by city. | |
| country | No | Returns customer records by country. | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Returns customer records created before the requested date (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns customer records created on or after the requested date (in UTC) | |
| excludeAccountingChangesFromModifiedDateRange | No | Excludes accounting changes such as balance adjustments from the modified date range. | |
| externalDataApplicationGuid | No | Format - guid. Returns customer records with external data for a particular GUID | |
| externalDataKey | No | ||
| externalDataValues | No | ||
| ids | No | Returns specific customer records by customer ID. | |
| includeTotal | No | Whether total count should be returned | |
| latitude | No | Format - double. Returns customer records by latitude. | |
| longitude | No | Format - double. Returns customer records by longitude. | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Returns customer records modified before the requested date (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns customer records modified after the requested date (in UTC) | |
| name | No | Returns customer records by name. | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| phone | No | Returns customer records by phone number of contacts. | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| state | No | Returns customer records by state. | |
| street | No | Returns customer records by street. | |
| tenant | Yes | Format - int64. Tenant ID | |
| unit | No | Returns customer records by unit. | |
| zip | No | Returns customer records by zip. |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_get_modified_contacts_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Returns items created before the requested date (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns items created on or after the requested date (in UTC) | |
| customerIds | No | Returns specific contact records by customer IDs. | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC). Either modifiedBefore or modifiedOnOrAfter parameter must be specified | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on/after certain date/time (in UTC). Either modifiedBefore or modifiedOnOrAfter parameter must be specified | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_getnotesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Returns notes created before the requested date (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns notes created on or after the requested date (in UTC) | |
| id | Yes | Format - int64. | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Returns notes modified before the requested date (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns notes modified after the requested date (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customers_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Whether the customer is active | |
| address | No | The address of the customer | |
| balance | No | The balance of the customer | |
| customFields | No | The custom fields of the customer | |
| doNotMail | No | Whether the customer should not be mailed | |
| doNotService | No | Whether the customer should not be serviced | |
| externalData | No | The external data of the customer | |
| id | Yes | Format - int64. | |
| mergedToId | No | The ID of the customer this customer was merged to | |
| name | No | The name of the customer | |
| tagTypeIds | No | The tag type IDs of the customer | |
| tenant | Yes | Format - int64. Tenant ID | |
| type | No | The type of the customer |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DiscountAndFees_CreateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Discount and fees account | |
| active | No | Discount and fees active | |
| amount | Yes | Discount and fees amount | |
| amountType | No | Discount and fees amount type | |
| assets | No | Discount and fees assets | |
| bonus | No | Discount and fees bonus | |
| categories | No | Discount and fees categories | |
| code | Yes | Discount and fees code | |
| commissionBonus | No | Discount and fees commission bonus | |
| crossSaleGroup | No | Discount and fees cross sale group | |
| description | No | Discount and fees description | |
| displayName | Yes | Discount and fees display name | |
| excludeFromPayroll | No | Discount and fees exclude from payroll | |
| externalData | No | Discount and fees external data | |
| hours | No | Discount and fees hours | |
| limit | No | Discount and fees limit | |
| paysCommission | No | Discount and fees pays commission | |
| taxable | No | Discount and fees taxable | |
| tenant | Yes | Format - int64. Tenant ID | |
| type | No | Discount and fees type |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DiscountAndFees_DeleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the SKU you are deleting | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discount_and_fees_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| externalDataApplicationGuid | No | Format - guid. Items that are created with a specific guid, could be fetched/updated/removed only when the same application guid is provided. | |
| id | Yes | Format - int64. The id of the discount and fee you are requesting | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discount_and_fees_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| externalDataApplicationGuid | No | Format - guid. Items that are created with a specific guid, could be fetched/updated/removed only when the same application guid is provided | |
| externalDataKey | No | Allows filtering by external data key | |
| externalDataValues | No | Allows filtering by external data values | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Code, DisplayName, CreatedOn, ModifiedOn, Price, MemberPrice, AddOnPrice, AddOnMemberPrice, MaterialsCost, PrimaryVendor, Cost, Manufacturer, Priority. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discount_and_fees_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The unique ID of the discount and fees to update | |
| payload | Yes | The properties of the discount and fees to update | |
| tenant | Yes | The tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dynamic_value_sets_get_dynamic_setD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dynamicSetId | Yes | ID of dynamic set taken from a report description | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
employees_accountactionsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
employees_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Request body (optional) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
employees_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
employees_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| name | No | Filters records by name (case-insensitive 'contains' operation) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID | |
| userIds | No | Perform lookup by multiple User Ids (maximum 50) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Employees_UpdateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| payload | No | The payload to update the employee | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
equipment_deleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Id of the SKU you are deleting | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
equipment_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| externalDataApplicationGuid | No | Format - guid. Items that are created with a specific guid, could be fetched/updated/removed only when the same application guid is provided. | |
| id | Yes | Format - int64. The id of the equipment you are requesting | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
equipment_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| externalDataApplicationGuid | No | Format - guid. Items that are created with a specific guid, could be fetched/updated/removed only when the same application guid is provided | |
| externalDataKey | No | Allows filtering by external data key | |
| externalDataValues | No | Allows filtering by external data values | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Code, DisplayName, CreatedOn, ModifiedOn, Price, MemberPrice, AddOnPrice, AddOnMemberPrice, MaterialsCost, PrimaryVendor, Cost, Manufacturer, Priority. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
equipment_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Unique id for the SKU is modified | |
| payload | No | The data to update the equipment with | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimates_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Active Flag | |
| businessUnitId | No | Business Unit ID | |
| customerId | No | Customer ID | |
| externalLinks | No | External Links | |
| items | No | Estimate Items | |
| jobId | No | Job ID | |
| jobNumber | No | Job Number | |
| locationId | No | Location ID | |
| name | No | Estimate Name | |
| projectId | No | Project ID | |
| soldBy | No | Sold By User ID | |
| soldOn | No | Sold On Date (string) | |
| statusValue | No | Status Value | |
| subtotal | No | Subtotal Amount | |
| summary | No | Estimate Summary | |
| tax | No | Tax Amount | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimates_delete_itemD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| itemId | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimates_dismissD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimates_export_estimatesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimates_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimates_get_itemsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| estimateId | No | Format - int64. | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimates_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| jobId | No | Format - int64. | |
| jobNumber | No | ||
| locationId | No | Format - int64. | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| orderBy | No | ||
| orderByDirection | No | ||
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| projectId | No | Format - int64. | |
| soldAfter | No | Format - date-time (as date-time in RFC3339). | |
| soldBefore | No | Format - date-time (as date-time in RFC3339). | |
| soldByEmployeeId | No | Format - int64. | |
| soldById | No | Format - int64. | |
| status | No | ||
| tenant | Yes | Format - int64. Tenant ID | |
| totalGreater | No | Format - decimal. | |
| totalLess | No | Format - decimal. |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimates_put_itemD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| chargeable | No | Chargeable | |
| description | No | Description | |
| id | Yes | Format - int64. Item ID | |
| itemGroupName | No | Item Group Name | |
| itemGroupRootId | No | Item Group Root ID | |
| membershipTypeId | No | Membership Type ID | |
| qty | No | Quantity | |
| skuAccount | No | SKU Account | |
| tenant | Yes | Format - int64. Tenant ID | |
| unitCost | No | Unit Cost | |
| unitRate | No | Unit Rate |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimates_sellD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimates_unsellD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimates_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| estimate | No | Estimate object to update | |
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_activitiesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export_ActivityCategoriesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_activitycodesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Include recent changes quickly | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_adjustmentsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_appointment_assignmentsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) | |
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_appointmentsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_bookings_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or date string | |
| includeRecentChanges | No | Include recent changes | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_business_unitsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Include recent changes | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_callsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Use true to receive recent changes quicker | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_contacts_customers_contactsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or date string | |
| includeRecentChanges | No | Include recent changes | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
exportcontacts_locationscontactsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_customers_get_customersD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_employeesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning. Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_equipmentD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or date string | |
| includeRecentChanges | No | Include recent changes | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_export_installed_equipmentD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export_GrossPayItemsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_inventory_billsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_invoice_itemsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token from previous export or custom date string (e.g., '2020-01-01') | |
| includeRecentChanges | No | Use 'true' for quicker recent changes (may cause duplicates) | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_invoicesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or date string | |
| includeRecentChanges | No | Include recent changes | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export_InvoiceTemplatesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_job_cancel_reasonsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Include recent changes quickly | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export_JobHistoryD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_jobnotesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or date string | |
| includeRecentChanges | No | Include recent changes flag | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_jobsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_job_splitsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Include recent changes for quicker results | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_leads_leadsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_location_recurring_service_eventsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or date string | |
| includeRecentChanges | No | Include recent changes quickly | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_location_recurring_servicesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token from previous export. Use custom date strings, e.g. "2020-01-01" to start from a certain time. | |
| includeRecentChanges | No | Use "true" to receive recent changes quicker. May cause duplicate results. | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_locations_locationsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_materialsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Include recent changes quickly | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_membershipsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Include recent changes quicker | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export_MembershipStatusChangesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Include recent changes quickly | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export_MembershipTypesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_paymentsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Receive recent changes quicker | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_payrolladjustmentsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export_PayrollSettingsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or date string | |
| includeRecentChanges | No | Include recent changes quicker | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export_ProjectNotesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Use true to receive recent changes quicker | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_projectsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Include recent changes quickly | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_purchase_ordersD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_recurring_service_typesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_returnsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_service_agreementsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_servicesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_tagtypesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_techniciansD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Include recent changes quickly | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_timesheetcodesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Use true to receive recent changes quicker | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export_TimesheetsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token or custom date string | |
| includeRecentChanges | No | Include recent changes quickly | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_transfersD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Continuation token received from previous export request in "continueFrom" field. When not specified, the export process starts from the beginning.\ Use custom date strings, e.g. "2020-01-01" to start the export process from the certain point in time. | |
| includeRecentChanges | No | Use "true" to start receiving the most recent changes quicker. Note this may cause the same results appearing multiple times on consecutive requests. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
external_call_attributions_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Tenant ID (int64) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
form_getformsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). | |
| hasConditionalLogic | No | Has conditional logic | |
| hasTriggers | No | Has triggers | |
| ids | No | IDs | |
| includeTotal | No | Include total | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). | |
| name | No | Name | |
| page | No | Format - int32. | |
| pageSize | No | Format - int32. | |
| sort | No | Sort | |
| status | No | Values: [Any, Published, Unpublished] | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
form_submission_get_form_submissionsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Values: [True, Any, False] | |
| createdById | No | Format - int64. Creator user Id | |
| formIds | No | Form Ids (comma separated Ids) | |
| includeTotal | No | Whether total count should be returned | |
| ownerType | No | Values: [Job, Call, Customer, Location, Equipment, Technician, JobAppointment, Membership, Truck] | |
| owners | No | List of owner object (one of Job,Customer,Location,Equipment,Call,Technician) {'type': 'xxx', 'id': 0000}\ \ Example: owners[0].type=Location&owners[0].id=2689281&\ owners[1].type=Customer&owners[1].id=2703496 | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field:\ "?sort=+FieldName" for ascending order,\ "?sort=-FieldName" for descending order.\ \ Available fields are: Id, SubmittedOn, CreatedBy. | |
| status | No | Values: [Started, Completed, Any] | |
| submittedBefore | No | Format - date-time (as date-time in RFC3339). Submission modified date before | |
| submittedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Submission modified date on or after | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
glaccounts_createaccountD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Whether the GL Account is active | |
| description | No | The description of the GL Account | |
| isIntacctBankAccount | No | Whether the GL Account is an Intacct bank account | |
| isIntacctGroup | No | Whether the GL Account is an Intacct group | |
| name | Yes | The name of the GL Account | |
| number | Yes | The number of the GL Account | |
| subtype | Yes | The subtype of the GL Account | |
| tenant | Yes | Tenant ID | |
| type | Yes | The type of the GL Account |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GlAccounts_GetAccountD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | Format - int64. Long integer id of the General Ledger account to be retrieved | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GlAccounts_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Specify if only active accounts, only inactive accounts, or both, should be retrieved. By default, only active accounts will be retrieved. Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| description | No | A substring that must be contained in the account description | |
| ids | No | Comma-delimited list of account IDs, maximum 50 items | |
| includeTotal | No | Whether total count should be returned | |
| isIntacctBankAccount | No | Set to true to retrieve Intacct bank accounts only | |
| isIntacctGroup | No | Set to true to retrieve Intacct group accounts only | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| names | No | Comma-delimited list of account names, maximum 50 items | |
| numbers | No | Comma-delimited list of account numbers, maximum 50 items | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by specified fields | |
| source | No | Account source Values: [Undefined, AccountingSystem, ManuallyCreated, PublicApi] | |
| subtypes | No | Comma-delimited list of account subtypes, maximum 50 items | |
| tenant | Yes | Format - int64. Tenant ID | |
| types | No | Comma-delimited list of account types, maximum 50 items |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gl_accounts_get_type_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Return items created on or after certain date/time (in UTC) | |
| ids | No | Comma-delimited list of account type IDs, maximum 50 items | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Return items modified on or after certain date/time (in UTC) | |
| names | No | Comma-delimited list of account type names, maximum 50 items | |
| page | No | The logical number of page to return, starting from 1 | |
| pageSize | No | How many records to return (50 by default) | |
| sort | No | Applies sorting by specified fields | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gl_accounts_update_accountD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | Format - int64. Long integer id of the General Ledger account to be updated | |
| payload | No | Payload for updating the GL Account. Omit to leave fields unchanged. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gps_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Request body for creating GPS data. | |
| gps_provider | Yes | The GPS Provider | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GrossPayItems_CreateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | The amount for the gross pay item | |
| description | No | A description of the gross pay item | |
| is_active | No | Whether the gross pay item is active | |
| name | Yes | The name of the gross pay item | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gross_pay_items_deleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. The gross pay item ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GrossPayItems_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dateOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items having date after certain date/time (in UTC) | |
| dateOnOrBefore | No | Format - date-time (as date-time in RFC3339). Return items having date before certain date/time (in UTC) | |
| employeeId | No | Format - int64. The Employee ID | |
| employeeType | No | The type of employee Values: [Technician, Employee] | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| payrollIds | No | The payroll ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gross_pay_items_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. The gross pay item ID | |
| payload | Yes | The payload for the update request | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
images_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | The storage path of the pricebook image to retrieve | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
images_postD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
installed_equipment_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| actualReplacementDate | No | Actual replacement date | |
| barcodeId | No | Barcode ID | |
| cost | No | Cost | |
| customerId | Yes | Customer ID | |
| equipmentId | Yes | Equipment ID | |
| installedOn | Yes | Date of installation | |
| invoiceItemId | No | Invoice Item ID | |
| locationId | Yes | Location ID | |
| manufacturer | No | Manufacturer | |
| manufacturerWarrantyEnd | No | Manufacturer warranty end date | |
| manufacturerWarrantyStart | No | Manufacturer warranty start date | |
| memo | No | Memo | |
| model | No | Model | |
| name | Yes | Name of the installed equipment | |
| predictedReplacementMonths | No | Predicted replacement months | |
| serialNumber | No | Serial number | |
| serviceProviderWarrantyEnd | No | Service provider warranty end date | |
| serviceProviderWarrantyStart | No | Service provider warranty start date | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
InstalledEquipment_GetD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
installed_equipment_get2D
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | The path for attachments | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
installed_equipment_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned | |
| createdBefore | No | Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| locationIds | No | Location IDs | |
| modifiedBefore | No | Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Return items modified on or after certain date/time (in UTC) | |
| page | No | The logical number of page to return, starting from 1 | |
| pageSize | No | How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
installed_equipment_post_attachmentD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | The file to upload (base64 encoded) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
installed_equipment_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | ||
| actualReplacementDate | No | ||
| barcodeId | No | ||
| cost | No | ||
| customerId | No | ||
| equipmentId | No | ||
| id | Yes | Format - int64. | |
| installedOn | No | ||
| invoiceItemId | No | ||
| locationId | No | ||
| manufacturer | No | ||
| manufacturerWarrantyEnd | No | ||
| manufacturerWarrantyStart | No | ||
| memo | No | ||
| model | No | ||
| name | No | ||
| predictedReplacementDate | No | ||
| predictedReplacementMonths | No | ||
| serialNumber | No | ||
| serviceProviderWarrantyEnd | No | ||
| serviceProviderWarrantyStart | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inventory_bills_get_custom_field_typesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inventory_bills_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| batchId | No | Format - int64. | |
| batchNumber | No | Format - int32. | |
| billNumber | No | ||
| businessUnitIds | No | ||
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customField.Fields | No | Dictionary of name-value pairs | |
| customField.Operator | No | Operator to be used between the name-value pairs. Can be "Or" or "And", default is "And". | |
| dateFrom | No | Format - date-time (as date-time in RFC3339). | |
| dateTo | No | Format - date-time (as date-time in RFC3339). | |
| ids | No | ||
| includeTotal | No | Whether total count should be returned | |
| jobNumber | No | ||
| maxCost | No | Format - decimal. | |
| minCost | No | Format - decimal. | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| purchaseOrderNumber | No | ||
| purchaseOrderTypes | No | ||
| syncStatuses | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inventory_bills_mark_as_exportedD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inventory_bills_update_custom_fieldsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| customFields | Yes | Custom fields to update | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoices_CreateAdjustmentInvoiceD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoices_delete_invoice_itemD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceId | Yes | Format - int64. | |
| itemId | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoices_getcustomfieldtypesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoices_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| adjustmentToId | No | Format - int64. When searching for adjustment invoices, this field will search for invoices that are adjustments to the specified invoice ID. | |
| assignedToIds | No | AssignedTo IDs associated with invoices. | |
| balanceFilter.Balance | No | Format - decimal. | |
| balanceFilter.Comparer | No | Values: [Equals, NotEquals, Greater, Less] | |
| batchId | No | Format - int64. Batch ID associated with invoices. | |
| batchNumber | No | Format - int32. Batch number associated with invoices. | |
| businessUnitId | No | Format - int64. Business unit ID associated with invoices. | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customField.Fields | No | Dictionary of name-value pairs | |
| customField.Operator | No | Operator to be used between the name-value pairs. Can be "Or" or "And", default is "And".\ Values: [And, Or] | |
| customerId | No | Format - int64. Customer ID associated with invoices. | |
| dueDateBefore | No | Format - date-time (as date-time in RFC3339). Retrieve all invoices with a due date before the input value | |
| dueDateOnOrAfter | No | Format - date-time (as date-time in RFC3339). Retrieve all invoices with a due date on after or equal the input value | |
| ids | No | Comma-delimited list of invoice IDs. | |
| includeTotal | No | Whether total count should be returned | |
| invoicedOnBefore | No | Format - date-time (as date-time in RFC3339). | |
| invoicedOnOrAfter | No | Format - date-time (as date-time in RFC3339). | |
| jobId | No | Format - int64. Job ID associated with invoices. This will be null if the invoice is not linked to a job. | |
| jobNumber | No | Job number associated with invoices. This will be null if the invoice is not linked to a job. | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| number | No | Reference number associated with invoices. | |
| orderBy | No | Field on which you want to order the returned list of invoices. | |
| orderByDirection | No | Order direction of the retuned list of invoices. Values of "desc" or "descending" will order the list in descending order, otherwise the list will be ordered in ascending order. | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| reviewStatuses | No | Review statuses associated with invoices. | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order.' | |
| statuses | No | Transaction status, which can be one of: Pending, Posted, Exported. By default, all transaction statuses are included. If you want to filter by more than one status, add a new "statuses" query parameter for each status you want to include. For example: &statuses=Pending&statuses=Posted | |
| tenant | Yes | Format - int64. Tenant ID | |
| totalGreater | No | Format - decimal. Retrieve all invoices with a total greater than or equal to the input value. | |
| totalLess | No | Format - decimal. Retrieve all invoices with a total less than or equal to the input value. |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoices_markasexportedD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoices_update_custom_fieldsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| custom_fields | Yes | Custom fields to update for the invoice | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoices_updateinvoiceD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| payload | No | The update payload | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoices_update_invoice_itemsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceId | Yes | Format - int64. | |
| payload | No | The request body as a JSON object. Each key represents a field to be updated. The values are the new values for the respective fields. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoice_templates_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | The payload to send in the request body | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoice_templates_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Invoice template ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoice_templates_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Invoice template ID | |
| payload | No | Invoice template update payload | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
job_cancel_reasons_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (active and inactive items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
job_hold_reasons_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (active and inactive items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_cancelD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_completeD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_create_attachmentD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | The file to upload (base64 encoded) | |
| id | Yes | Format - int64. Job Id | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_create_messageD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| message | Yes | The message to create | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_create_noteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID | |
| text | Yes | Note text |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_get_attachmentD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. The id of the job attachment to retrieve, as returned by other job API endpoints. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_get_booked_logD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_get_cancel_reasonsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Perform lookup by multiple IDs (maximum 50) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_get_custom_field_typesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_gethistoryD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_get_job_attachmentsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). | |
| includeTotal | No | ||
| jobId | Yes | Format - int64. Job Id | |
| page | No | Format - int32. | |
| pageSize | No | Format - int32. | |
| sort | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_get_job_canceled_logsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| appointmentStartsBefore | No | Format - date-time (as date-time in RFC3339). Return jobs if any appointment starts after date/time (in UTC) | |
| appointmentStartsOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return jobs if any appointment starts after date/time (in UTC) | |
| appointmentStatus | No | Filters by appointment status. Return a job if it has any appointment with the specified status. Values: [Scheduled, Dispatched, Working, Hold, Done, Canceled] | |
| bookingId | No | Format - int64. Filters by booking ID that resulted in this job | |
| businessUnitId | No | Format - int64. Filters by job's business unit ID | |
| campaignId | No | Format - int64. Filters by job's campaign ID | |
| completedBefore | No | Format - date-time (as date-time in RFC3339). Return jobs that are completed before a certain date/time (in UTC) | |
| completedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return jobs that are completed after a certain date/time (in UTC) | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customerId | No | Format - int64. Filters by job's customer ID | |
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| externalDataKey | No | Performs lookup by external data key, 'externalDataValues' must also be provided. | |
| externalDataValues | No | Performs lookup by external data values (maximum 50), 'externalDataKey' must also be provided. | |
| firstAppointmentStartsBefore | No | Format - date-time (as date-time in RFC3339). Return jobs whose first appointment starts before date/time (in UTC) | |
| firstAppointmentStartsOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return jobs whose first appointment starts on or after date/time (in UTC). Use with "firstAppointmentStartsBefore" to find jobs whose first appointment is within the specified date range. | |
| hasUnusedAppointments | No | If set to true, return jobs that have unused appointments. | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| invoiceId | No | Format - int64. Filters by job's invoice ID | |
| jobStatus | No | Filters by job status Values: [Scheduled, Dispatched, InProgress, Hold, Completed, Canceled] | |
| jobTypeId | No | Format - int64. Filters by job type ID | |
| locationId | No | Format - int64. Filters by job's location ID | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| number | No | Filters by job number | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| priority | No | Filters by priority. Supported priorities are "Low", "Normal", "High", "Urgent" | |
| projectId | No | Format - int64. Filters by project ID | |
| soldById | No | Format - int64. Filters by the technician who sold the job | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn, Priority. | |
| tagTypeIds | No | Return jobs that have at least one of provided Tag Type assigned | |
| technicianId | No | Format - int64. Return jobs if technician is assigned to any appointment | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_getnotesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_holdD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
job_splits_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Returns job split by active status Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return job splits created before a certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns job split created on or after a certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| job | Yes | Format - int64. | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Returns job split modified before a certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns job split modified on or after a certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
job_splits_get_list_by_jobsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Returns job split by active status Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return job splits created before a certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns job split created on or after a certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| jobIds | No | ||
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Returns job split modified before a certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns job split modified on or after a certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_remove_cancellationD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobs_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | The request body | |
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JobTypes_CreateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Whether the job type is active | |
| businessUnitIds | Yes | List of business unit IDs | |
| class | Yes | Class of the job type | |
| duration | Yes | Duration of the job type | |
| enforceRecurringServiceEventSelection | Yes | Whether to enforce recurring service event selection | |
| externalData | No | External data for the job type | |
| invoiceSignaturesRequired | Yes | Whether invoice signatures are required | |
| name | Yes | Name of the job type | |
| noCharge | Yes | Whether the job type is no charge | |
| priority | Yes | Priority of the job type | |
| skills | Yes | List of skills | |
| soldThreshold | Yes | Sold threshold | |
| summary | Yes | Summary of the job type | |
| tagTypeIds | Yes | List of tag type IDs | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
job_types_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobtypes_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default)\ Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| maxDuration | No | Format - int32. Maximum length of time for this job type (in seconds) | |
| minDuration | No | Format - int32. Minimum length of time for this job type (in seconds) | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| name | No | Filters by job type name | |
| orderBy | No | Orders results by a field. Supported fields are "id", "modifiedOn", and "createdOn" | |
| orderByDirection | No | Specifies order direction of results. Supported values are "asc"/"ascending" and "desc"/"descending" | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| priority | No | Level of urgency for this type of job | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jobtypes_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | ||
| businessUnitIds | No | ||
| class | No | ||
| duration | No | ||
| enforceRecurringServiceEventSelection | No | ||
| externalData | No | ||
| id | Yes | Format - int64. | |
| invoiceSignaturesRequired | No | ||
| name | No | ||
| noCharge | No | ||
| priority | No | ||
| skills | No | ||
| soldThreshold | No | ||
| summary | No | ||
| tagTypeIds | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
journal_entries_get_detailsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - guid. | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default). Maximum value is 500. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
journal_entries_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| businessUnitIds | No | Comma-delimited list of business unit IDs, maximum 50 items | |
| createdBefore | No | Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Return items created on or after certain date/time (in UTC) | |
| customField | No | Filter by custom fields associated with journal entries. Example: ?customField.fieldName1=value1&customField.fieldName2=value2. A field with null value, and a non-existent field are treated equally. Maximum 5 custom fields are supported in one request. | |
| customerName | No | Contains a transaction for a customer with name containing | |
| exportedBy | No | Comma-delimited list of user IDs, maximum 50 items | |
| exportedFrom | No | Exported on or after certain date/time (in UTC) | |
| exportedTo | No | Exported on or before certain date/time (in UTC) | |
| ids | No | Comma-delimited list of journal entry IDs, maximum 50 items | |
| includeTotal | No | Whether total count should be returned | |
| inventoryLocationName | No | Contains a transaction for an inventory location with name containing | |
| locationName | No | Contains a transaction for a customer location with name containing | |
| modifiedBefore | No | Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Return items modified on or after certain date/time (in UTC) | |
| name | No | Name contains | |
| numberFrom | No | Number is greater or equal than | |
| numberTo | No | Number is less or equal to | |
| page | No | The logical number of page to return, starting from 1 | |
| pageSize | No | How many records to return (50 by default). Maximum value is 500. | |
| postedFrom | No | Posted on or after certain date/time (in UTC) | |
| postedTo | No | Posted on or before certain date/time (in UTC) | |
| refNumber | No | Contains a transaction with reference number containing | |
| serviceAgreementIds | No | Comma-delimited list of service agreement IDs, maximum 50 items | |
| sort | No | Applies sorting by the specified field and direction. Options: Id, Number, Name, Status, CreatedOn, ExportedOn, ExportedBy, PostDate. Use "+" for ascending order, and "-" for descending order. Example: "?sort=-Number" will sort by number in descending order. | |
| statuses | No | Array of statuses | |
| syncStatuses | No | Array of sync statuses | |
| tenant | Yes | Tenant ID | |
| transactionPostedFrom | No | Contains a transaction posted on or after certain date/time (in UTC) | |
| transactionPostedTo | No | Contains a transaction posted on or before certain date/time (in UTC) | |
| transactionTypes | No | List of transaction types. A journal entry will be returned if it contains at least one transaction of this type. | |
| vendorName | No | Contains a transaction for a vendor with name containing |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
journal_entries_get_summaryD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - guid. | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default). Maximum value is 500. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
journal_entries_sync_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The Journal Entry ID (UUID) | |
| tenant | Yes | The Tenant ID (int64) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
journal_entries_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - guid. | |
| payload | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
leads_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Request Body | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
leads_create_follow_upD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| followUpDate | Yes | Follow up date | |
| id | Yes | Format - int64. | |
| pinToTop | Yes | Pin to top | |
| tenant | Yes | Format - int64. Tenant ID | |
| text | Yes | Follow up text |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
leads_create_noteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| isPinned | No | Whether the note is pinned | |
| tenant | Yes | Format - int64. Tenant ID | |
| text | Yes | Note text |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
leads_dismissD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
leads_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Leads_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customerCity | No | Filters by customer city | |
| customerCreatedBefore | No | Format - date-time (as date-time in RFC3339). Returns customers who were created after a certain date/time (in UTC) | |
| customerCreatedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns customers who were created on or before a certain date/time (in UTC) | |
| customerId | No | Format - int64. Filters by associated customer | |
| customerModifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns customers who were modified on or before a certain date/time (in UTC) | |
| customerState | No | Filters by customer state | |
| customerZip | No | Filters by customer zip | |
| genPermUrl | No | If true, generates a permanent URL for the lead | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| isProspect | No | Allows to filter leads where the customer doesn't have a job, or there is no customer. Possible values are: null (return all leads); true (return leads without customer/jobs); false (return leads with customer and job) | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| status | No | Filters by status Values: [Open, Dismissed, Converted] | |
| tenant | Yes | Format - int64. Tenant ID | |
| withoutCustomer | No | Allows to filter leads that don't have a customer or location record associated to it. Possible values are: null (return all leads); true (return leads without customers or locations only); false (return leads with customers and locations only) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
leads_getnotesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Returns notes created before the requested date (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns notes created on or after the requested date (in UTC) | |
| id | Yes | Format - int64. | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Returns notes modified before the requested date (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns notes modified after the requested date (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
leads_submitLeadFormD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
leads_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | The request body. | |
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
location_labor_type_get_list_by_locationsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| locationIds | No | Returns location rates for the specified location IDs | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Location (sorts by locations Id), CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
location_recurring_service_events_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| jobId | No | Format - int64. Job ID | |
| locationId | No | Format - int64. Location ID | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| status | No | Follow up status Values: [NotAttempted, Unreachable, Contacted, Won, Dismissed] | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
location_recurring_service_events_mark_completeD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recurring service event ID | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
location_recurring_service_events_mark_incompleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Recurring service event ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
location_recurring_services_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recurring service ID | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
location_recurring_services_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| locationIds | No | Filters by location IDs | |
| membershipIds | No | Filters by customer membership IDs | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
location_recurring_services_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recurring service ID | |
| payload | No | The request payload | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Location Active | |
| address | No | Address Details | |
| contacts | No | Contacts | |
| customFields | No | Custom Fields | |
| customerId | No | Customer ID | |
| externalData | No | External Data | |
| name | No | Location Name | |
| tagTypeIds | No | Tag Type IDs | |
| taxZoneId | No | Tax Zone ID | |
| tenant | Yes | Format - int64. Tenant ID | |
| zoneId | No | Zone ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_createcontactD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| doNotText | No | Do not text flag for phone settings | |
| id | Yes | Format - int64. | |
| memo | No | Contact memo | |
| phoneNumber | No | Phone number for phone settings | |
| tenant | Yes | Format - int64. Tenant ID | |
| type | Yes | Contact type | |
| value | Yes | Contact value |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_create_noteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| isPinned | No | Whether the note should be pinned. Defaults to false. | |
| tenant | Yes | Format - int64. Tenant ID | |
| text | Yes | The text of the note. |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_create_tagD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tagTypeId | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_delete_contactD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | Format - int64. | |
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_delete_noteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| noteId | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_delete_tagD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tagTypeId | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_get_contact_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_get_custom_field_typesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| city | No | Filters by customer's city | |
| country | No | Filters by customer's country | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customerId | No | Format - int64. Filters by customer ID | |
| externalDataApplicationGuid | No | Format - guid. Returns location records with external data for a particular GUID | |
| externalDataKey | No | Performs lookup by external data key, 'externalDataValues' must also be provided. | |
| externalDataValues | No | Performs lookup by external data values (maximum 50), 'externalDataKey' must also be provided. | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| latitude | No | Format - double. Filters by customer's latitude | |
| longitude | No | Format - double. Filters by customer's longitude | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| name | No | Filters by customer's name | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| state | No | Filters by customer's state | |
| street | No | Filters by customer's street | |
| tenant | Yes | Format - int64. Tenant ID | |
| unit | No | Filters by customer's unit | |
| zip | No | Filters by customer's zip |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_getlocationscontactslistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Returns items created before the requested date (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns items created on or after the requested date (in UTC) | |
| includeTotal | No | ||
| locationIds | No | Returns specific contact records by location IDs. | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC). Either modifiedBefore or modifiedOnOrAfter parameter must be specified | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on/after certain date/time (in UTC). Either modifiedBefore or modifiedOnOrAfter parameter must be specified | |
| page | No | Format - int32. | |
| pageSize | No | Format - int32. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_getnotesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Returns notes created before the requested date (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns notes created on or after the requested date (in UTC) | |
| id | Yes | Format - int64. | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Returns notes modified before the requested date (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Returns notes modified after the requested date (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_update_contactD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | Format - int64. Contact ID | |
| doNotText | No | Do not text flag for the contact | |
| id | Yes | Format - int64. Location ID | |
| memo | No | Contact memo | |
| phoneNumber | No | Phone number for the contact | |
| tenant | Yes | Format - int64. Tenant ID | |
| value | No | Contact value |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
materials_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
materials_deleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Id of the SKU you are deleting | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
materials_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| externalDataApplicationGuid | No | Format - guid. Items that are created with a specific guid, could be fetched/updated/removed only when the same application guid is provided. | |
| id | Yes | Format - int64. The id of the material you are requesting | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
materials_get_cost_typesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
materials_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| costTypeIds | No | Allows filtering by Cost Type Ids | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| externalDataApplicationGuid | No | Format - guid. Items that are created with a specific guid, could be fetched/updated/removed only when the same application guid is provided | |
| externalDataKey | No | Allows filtering by external data key | |
| externalDataValues | No | Allows filtering by external data values | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| isOtherDirectCost | No | Allows filtering by Is Other Direct Cost | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Code, DisplayName, CreatedOn, ModifiedOn, Price, MemberPrice, AddOnPrice, AddOnMemberPrice, MaterialsCost, PrimaryVendor, Cost, Manufacturer, Priority. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
materialsmarkup_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
materialsmarkup_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Materials markup id | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
materialsmarkup_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Format - int32. | |
| pageSize | No | Format - int32. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
materialsmarkup_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Starting value for the markup range | |
| id | Yes | Format - int64. Materials markup id | |
| percent | No | Markup percentage | |
| tenant | Yes | Format - int64. Tenant ID | |
| to | No | Ending value for the markup range |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
materials_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Material account | |
| active | No | Material active status | |
| addOnMemberPrice | No | Material add-on member price | |
| addOnPrice | No | Material add-on price | |
| assetAccount | No | Material asset account | |
| assets | No | ||
| bonus | No | Material bonus | |
| businessUnitId | No | Material business unit ID | |
| categories | No | ||
| chargeableByDefault | No | Material chargeable by default status | |
| code | No | Material code | |
| commissionBonus | No | Material commission bonus | |
| cost | No | Material cost | |
| costOfSaleAccount | No | Material cost of sale account | |
| costTypeId | No | Material cost type ID | |
| deductAsJobCost | No | Material deduct as job cost status | |
| description | No | Material description | |
| displayInAmount | No | Material display in amount status | |
| displayName | No | Material display name | |
| externalData | No | ||
| externalId | No | Material external ID | |
| generalLedgerAccountId | No | Material general ledger account ID | |
| hours | No | Material hours | |
| id | Yes | Format - int64. Unique id for the SKU is modified | |
| isConfigurableMaterial | No | Material is configurable material status | |
| isInventory | No | Material is inventory status | |
| isOtherDirectCost | No | Material is other direct cost status | |
| memberPrice | No | Material member price | |
| otherVendors | No | ||
| paysCommission | No | Material pays commission status | |
| price | No | Material price | |
| primaryVendor | No | ||
| source | No | Material source | |
| taxable | No | Material taxable status | |
| tenant | Yes | Format - int64. Tenant ID | |
| unitOfMeasure | No | Material unit of measure | |
| variationsOrConfigurableMaterials | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
membership_types_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Membership type ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
membership_types_get_discounts_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Membership type ID | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
membership_types_get_duration_billing_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| id | Yes | Format - int64. Membership type ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
membership_types_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| billingFrequency | No | Filters by membership billing frequency Values: [OneTime, Monthly, EveryOtherMonth, Quarterly, BiAnnual, Annual] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| duration | No | Format - int32. Filters by membership duration (in months); use null for ongoing memberships | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeDurationBilling | No | Whether duration/billing should be included in the result | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
membership_types_get_recurring_service_itemsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Membership type ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NonJobAppointments_CreateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Active appointment | |
| allDay | No | All day appointment | |
| clearDispatchBoard | No | Clear dispatch board | |
| clearTechnicianView | No | Clear technician view | |
| countOccurrences | No | Count occurrences | |
| daysOfWeek | No | Days of week (e.g., Mon,Tue) | |
| duration | Yes | Appointment duration | |
| endOn | No | End date | |
| endType | No | End type (e.g., on, after) | |
| frequency | No | Frequency (e.g., daily, weekly) | |
| interval | No | Interval | |
| name | Yes | Appointment name | |
| removeTechnicianFromCapacityPlanning | No | Remove technician from capacity planning | |
| repeat | No | Repeat appointment | |
| showOnTechnicianSchedule | No | Show on technician schedule | |
| start | Yes | Start date/time | |
| summary | No | Appointment summary | |
| technicianId | Yes | Technician ID | |
| tenant | Yes | Tenant ID | |
| timesheetCodeId | Yes | Timesheet code ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
non_job_appointments_deleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The non-job appointment ID (int64). | |
| tenant | Yes | The tenant ID (int64). |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NonJobAppointments_GetD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
non_job_appointments_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| activeOnly | No | Whether the result should contains only active non-job appointments | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| showOnTechnicianSchedule | No | Whether the non-job appointment shows on the technicians schedule even if there is no timesheet | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, CreatedOn, ModifiedOn. | |
| startsOnOrAfter | No | Format - date-time (as date-time in RFC3339). When the Start of non-job appointment should be at or after | |
| startsOnOrBefore | No | Format - date-time (as date-time in RFC3339). When the Start of non-job appointment should be at or before | |
| technicianId | No | Format - int64. Unique id of the technician this non-job appointment applies to | |
| tenant | Yes | Format - int64. Tenant ID | |
| timesheetCodeId | No | Format - int64. Unique Id of timesheet code must apply to |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NonJobAppointments_UpdateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Active appointment flag | |
| allDay | No | All-day appointment flag | |
| clearDispatchBoard | No | Clear dispatch board flag | |
| clearTechnicianView | No | Clear technician view flag | |
| duration | No | Appointment duration | |
| id | Yes | Non-Job Appointment ID | |
| name | No | Appointment name | |
| removeTechnicianFromCapacityPlanning | No | Remove technician from capacity planning flag | |
| showOnTechnicianSchedule | No | Show on technician schedule flag | |
| start | No | Appointment start time | |
| summary | No | Appointment summary | |
| technicianId | No | Technician ID | |
| tenant | Yes | Tenant ID | |
| timesheetCodeId | No | Timesheet code ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
opt_in_out_create_opt_out_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contact_numbers | Yes | List of contact numbers to opt-out | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
opt_in_out_get_all_opt_outsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OptInOut_GetOptOutListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Array of contact numbers to check | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payments_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payments_get_custom_field_typesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payments_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| appliedToInvoiceIds | No | ||
| appliedToReferenceNumber | No | ||
| batchId | No | Format - int64. | |
| batchNumber | No | Format - int32. | |
| businessUnitIds | No | ||
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customField.Fields | No | Dictionary of name-value pairs | |
| customField.Operator | No | Operator to be used between the name-value pairs. Can be "Or" or "And", default is "And". Values: [And, Or] | |
| customerId | No | Format - int64. | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| paidOnAfter | No | Format - date-time (as date-time in RFC3339). | |
| paidOnBefore | No | Format - date-time (as date-time in RFC3339). | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. | |
| statuses | No | ||
| tenant | Yes | Format - int64. Tenant ID | |
| totalGreater | No | Format - decimal. | |
| totalLess | No | Format - decimal. | |
| transactionType | No | Values: [Undefined, JournalEntry, ReceivePayment] |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payments_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| payload | No | Payment details to update | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Payments_UpdateCustomFieldsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| custom_fields | Yes | Custom fields to update | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Payments_UpdateStatusD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
paymentterms_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | ||
| modifiedOnOrAfter | No | ||
| page | No | The logical number of page to return, starting from 1 | |
| pageSize | No | How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Name, CreatedOn. | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payment_terms_get_payment_term_modelD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| paymentTermId | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PaymentTypes_GetD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payment_types_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PayrollAdjustments_CreateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Request body for creating payroll adjustments | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payroll_adjustments_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| employeeType | No | The employee type | |
| id | Yes | The ID of payroll adjustment | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PayrollAdjustments_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| employeeIds | No | The comma separated list of employee IDs | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| postedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return payroll adjustments posted on or after certain date/time (in UTC) | |
| postedOnOrBefore | No | Format - date-time (as date-time in RFC3339). Return payroll adjustments posted on or before certain date/time (in UTC) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PayrollSettings_GetEmployeePayrollSettingsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| employee | Yes | Format - int64. The employee ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PayrollSettings_GetPayrollSettingsListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| employeeType | No | The type of employee Values: [Technician, Employee] | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PayrollSettings_GetTechnicianPayrollSettingsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| technician | Yes | Format - int64. The technician ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PayrollSettings_UpdateEmployeePayrollSettingsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| employee | Yes | Format - int64. The employee ID | |
| payload | Yes | Request Body | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PayrollSettings_UpdateTechnicianPayrollSettingsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| employeeId | No | Employee ID | |
| technician | Yes | Format - int64. The technician ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Payrolls_GetEmployeePayrollsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| approvedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items approved on or after certain date/time (in UTC) | |
| employee | Yes | Format - int64. The employee ID | |
| endedOnOrBefore | No | Format - date-time (as date-time in RFC3339). Return items having end date before certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| startedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items having start date after certain date/time (in UTC) | |
| status | No | Return items of the specified payroll status Values: [Pending, Expired, Approved, Paid, Locked] | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Payrolls_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default). Values: [True, Any, False] | |
| approvedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items approved on or after certain date/time (in UTC) | |
| employeeType | No | The type of employee. Values: [Technician, Employee] | |
| endedOnOrBefore | No | Format - date-time (as date-time in RFC3339). Return items having end date before certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| startedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items having start date after certain date/time (in UTC) | |
| status | No | Return items of the specified payroll status. Values: [Pending, Expired, Approved, Paid, Locked] | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payrolls_get_technician_payrollsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| approvedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items approved on or after certain date/time (in UTC) | |
| endedOnOrBefore | No | Format - date-time (as date-time in RFC3339). Return items having end date before certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| startedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items having start date after certain date/time (in UTC) | |
| status | No | Return items of the specified payroll status Values: [Pending, Expired, Approved, Paid, Locked] | |
| technician | Yes | Format - int64. The technician ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
performance_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| fromUtc | Yes | Format - date-time (as date-time in RFC3339). Gets or sets the start date and time in UTC for the filtering period. | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| performanceSegmentationType | Yes | Gets or sets the type of performance segmentation for filtering purposes. | |
| tenant | Yes | Format - int64. Tenant ID | |
| toUtc | Yes | Format - date-time (as date-time in RFC3339). Gets or sets the end date and time in UTC for the filtering period. |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pricebookbulk_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | The payload for bulk pricebook creation. This should match the expected schema for the API. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pricebookbulk_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_attach_jobD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| jobId | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_create_messageD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| message | Yes | The message to create | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_create_noteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| isPinned | No | Whether the note is pinned | |
| tenant | Yes | Format - int64. Tenant ID | |
| text | Yes | Note text |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_detach_jobD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_get_custom_field_typesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| appointmentId | No | Format - int64. Return project if it contains the specified appointment in the project's jobs | |
| businessUnitIds | No | Returns projects which have at least one of the provided business units assigned | |
| completedBefore | No | Format - date-time (as date-time in RFC3339). Return projects that are completed before date | |
| completedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return projects that are completed on or after date | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customerId | No | Format - int64. Filters by customer ID | |
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| externalDataKey | No | Performs lookup by external data key, 'externalDataValues' must also be provided. | |
| externalDataValues | No | Performs lookup by external data values (maximum 50), 'externalDataKey' must also be provided. | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| invoiceId | No | Format - int64. Return projects if it contains the specified invoice | |
| jobId | No | Format - int64. Return project if it contains the specified job | |
| locationId | No | Format - int64. Filters by location ID | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return projects whose last modification date is before date | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return projects whose last modification date is on or after date | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| projectManagerIds | No | Filters by id of managers for matching project | |
| projectTypeId | No | Format - int64. Return projects if it contains the specified project type | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn, Name, TargetCompletionDate. | |
| startsBefore | No | Format - date-time (as date-time in RFC3339). Return projects that start before date | |
| startsOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return projects that start on or after date | |
| status | No | Returns projects which have one of the provided statuses. "None" could be passed as one of the values to include projects without a status in the resulting collection. | |
| targetCompletionDateBefore | No | Format - date-time (as date-time in RFC3339). Return projects whose target completion date is before date | |
| targetCompletionDateOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return projects whose target completion date is on or after date | |
| technicianId | No | Format - int64. Return project if technician is assigned to any appointments on any job in the project | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_get_notesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ProjectStatuses_GetD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ProjectStatuses_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| name | No | Filters by project status name | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Name, Order, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
project_substatuses_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
project_sub_statuses_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| name | No | Filters by project sub status name | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Name, Order, StatusId, ModifiedOn, CreatedOn. | |
| statusId | No | Format - int64. Filters by parent project status id | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| actualCompletionDate | No | Project Actual Completion Date | |
| businessUnitIds | No | Business Unit IDs | |
| customFields | No | Custom Fields | |
| customerId | No | Customer ID | |
| externalData | No | External Data | |
| id | Yes | Format - int64. Project ID | |
| jobIds | No | Job IDs | |
| locationId | No | Location ID | |
| name | No | Project Name | |
| number | No | Project Number | |
| projectManagerIds | No | Project Manager IDs | |
| projectTypeId | No | Project Type ID | |
| startDate | No | Project Start Date | |
| status | No | Project Status | |
| statusId | No | Project Status ID | |
| subStatus | No | Project Sub Status | |
| subStatusId | No | Project Sub Status ID | |
| summary | No | Project Summary | |
| targetCompletionDate | No | Project Target Completion Date | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
project_types_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
project_types_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_orders_approve_requestD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The purchase order request ID (int64). | |
| tenant | Yes | The tenant ID (int64). |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_orders_cancelD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Return Id | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_orders_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Request Body | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_orders_get_by_idD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. The purchase order ID. | |
| tenant | Yes | Format - int64. Tenant ID. |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_orders_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| dateBefore | No | Format - date-time (as date-time in RFC3339). Return POs with date before certain date/time | |
| dateOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return POs with date on or after certain date/time | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| jobId | No | Format - int64. Filters by JobId associated with PO | |
| jobIds | No | Filters by JobIds associated with PO | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| number | No | Filters by PO number | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| projectId | No | Format - int64. Filter by ProjectId associated with PO | |
| sentBefore | No | Format - date-time (as date-time in RFC3339). Return POs sent before certain date/time | |
| sentOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return POs sent on or after certain date/time | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| status | No | Filters by PO status Available values are: Pending, Sent, PartiallyReceived, Received, Exported, Canceled | |
| technicianId | No | Format - int64. Filter by TechnicianId associated with PO | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_orders_getrequestsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| dateBefore | No | Format - date-time (as date-time in RFC3339). Return PO requests with date before certain date/time | |
| dateOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return PO requests with date on or after certain date/time | |
| ids | No | ||
| includeTotal | No | Whether total count should be returned | |
| jobId | No | Format - int64. Filters by JobId associated with PO request | |
| jobIds | No | Filters by JobIds associated with PO request | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| projectId | No | Format - int64. Filter by ProjectId associated with PO request | |
| requestNumber | No | Filters by PO request number | |
| requestStatus | No | Filters by PO request status Available values are: PendingApproval, Rejected\ Values: [PendingApproval, Approved, Rejected] | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| technicianId | No | Format - int64. Filter by TechnicianId associated with PO request | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PurchaseOrdersMarkup_CreateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Starting value for the markup range | |
| percent | No | Markup percentage to apply | |
| tenant | Yes | Format - int64. Tenant ID | |
| to | No | Ending value for the markup range |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_orders_markup_deleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_orders_markup_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Purchase order markup IDs | |
| includeTotal | No | ||
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. | |
| pageSize | No | Format - int32. | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, From, To, Percent | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_orders_markup_get_by_idD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PurchaseOrdersMarkup_UpdateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdOn | No | ||
| from | No | ||
| id | Yes | Format - int64. | |
| modifiedOn | No | ||
| percent | No | ||
| tenant | Yes | Format - int64. Tenant ID | |
| to | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PurchaseOrders_RejectRequestD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Existing PoRequest Id | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_orders_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PurchaseOrderTypes_CreateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PurchaseOrderTypes_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_order_types_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Purchase Order Type ID | |
| payload | Yes | The payload to update the Purchase Order Type | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
receipts_cancelreceiptsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Receipt ID | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
receipts_create_receiptD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
receipts_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| batchId | No | Format - int64. BatchId filter | |
| billId | No | Format - int64. BillId filter | |
| businessUnitIds | No | Filter by a collection of business units | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customFields.Fields | No | Collection of custom field pairs (name, value) to filter by | |
| customFields.Operator | No | Can be "Or" or "And" Values: [And, Or] | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| inventoryLocationIds | No | Filter by a collection of inventory locations | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| number | No | Number filter | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| purchaseOrderIds | No | Filter by a collection of purchase orders | |
| receivedBefore | No | Format - date-time (as date-time in RFC3339). Return receipts with received date before certain date/time | |
| receivedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return receipts with received date on or after certain date/time | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| syncStatuses | No | Filter by a collection of sync statuses | |
| tenant | Yes | Format - int64. Tenant ID | |
| vendorIds | No | Filter by a collection of vendors | |
| vendorInvoiceNumber | No | Vendor invoice number filter |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
receipts_update_custom_fieldsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| customFields | No | Custom fields to update. A map of key-value pairs. | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recurring_service_types_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Recurring service type ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recurring_service_types_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| durationType | No | Filters by duration type Values: [Continuous, NumberOfVisits] | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| membershipTypeId | No | Format - int64. Filters by membership type ID | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| recurrenceType | No | Filters by recurrence type Values: [Weekly, Monthly, Seasonal, Daily, NthWeekdayOfMonth] | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Name, CreatedOn, ModifiedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ReportCategories_GetCategoriesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ReportCategoryReports_GetD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| reportId | Yes | Format - int64. ID of report within the category | |
| report_category | Yes | ID of category taken from the category list endpoint | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_category_reports_get_dataD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| includeTotal | No | Whether total count should be returned | |
| page | No | The logical number of page to return, starting from 1 | |
| pageSize | No | How many records to return (1000 by default) | |
| reportId | Yes | ID of report within the category | |
| report_category | Yes | ID of category taken from the category list endpoint | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_category_reports_get_reportsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| report_category | Yes | ID of category taken from the category list endpoint | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
returns_cancelD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Return Id | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
returns_create_returnD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
returns_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| batchId | No | Format - int64. Batch filter | |
| businessUnitIds | No | Filter by a collection of business units | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customFields.Fields | No | Collection of custom field pairs (name, value) to filter by | |
| customFields.Operator | No | Can be "Or" or "And" Values: [And, Or] | |
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| externalDataKey | No | Performs lookup by external data key, 'externalDataValues' must also be provided. | |
| externalDataValues | No | Performs lookup by external data values (maximum 50), 'externalDataKey' must also be provided. | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| inventoryLocationIds | No | Filter by a collection of inventory locations | |
| jobId | No | Format - int64. Job filter | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| number | No | Number filter | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| purchaseOrderId | No | Format - int64. Purchase order filter | |
| referenceNumber | No | Reference number filter | |
| returnDateBefore | No | Format - date-time (as date-time in RFC3339). Filters by returns with return date before certain date/time | |
| returnDateOnOrAfter | No | Format - date-time (as date-time in RFC3339). Filters by returns with return date on or after certain date/time | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| syncStatuses | No | Filter by a collection of sync statuses | |
| tenant | Yes | Format - int64. Tenant ID | |
| vendorIds | No | Filter by a collection of vendors |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
returns_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Return Id | |
| payload | No | JSON payload for update | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
returns_update_custom_fieldsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| customFields | Yes | Custom fields to update | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
return_types_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
return_types_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| activeOnly | Yes | Filter by active only | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| name | No | Filter by name | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by specified fields | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
return_types_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Return Type Id | |
| payload | No | Payload for the update request | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reviewsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| campaignIds | No | ||
| createdBefore | No | Format - date-time (as date-time in RFC3339). | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). | |
| fromDate | No | Format - date-time (as date-time in RFC3339). | |
| fromRating | No | Format - float. | |
| includeReviewsWithoutCampaign | No | ||
| includeReviewsWithoutLocation | No | ||
| includeReviewsWithoutTechnician | No | ||
| includeTotal | No | ||
| locationIds | No | ||
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). | |
| page | No | Format - int32. | |
| pageSize | No | Format - int32. | |
| reportType | No | Format - int32. | |
| responseTypes | No | ||
| reviewStatuses | No | ||
| search | No | ||
| sort | No | ||
| sources | No | ||
| technicianIds | No | ||
| tenant | Yes | The tenant identifier. | |
| toDate | No | Format - date-time (as date-time in RFC3339). | |
| toRating | No | Format - float. |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scheduled_job_attributions_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scheduler_scheduler_performanceD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Scheduler ID | |
| sessionCreatedBefore | Yes | Session created before (date-time in RFC3339) | |
| sessionCreatedOnOrAfter | Yes | Session created on or after (date-time in RFC3339) | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scheduler_schedulersD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scheduler_schedulersessionsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| id | Yes | Scheduler ID | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
service_agreements_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Service agreement ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ServiceAgreements_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| businessUnitIds | No | Filters by business unit IDs | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customerIds | No | Filters by customer IDs | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Name, CreatedOn, ModifiedOn, StartDate, EndDate | |
| status | No | Filters by service agreement status Values: [Draft, Sent, Rejected, Accepted, Activated, Canceled, Expired, AutoRenew] | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
services_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Account Number | |
| active | No | Is Active | |
| addOnMemberPrice | No | Add-On Member Price | |
| addOnPrice | No | Add-On Price | |
| bonus | No | Bonus Amount | |
| businessUnitId | No | Business Unit ID | |
| categoryIds | No | Array of Category IDs | |
| code | Yes | Service Code | |
| commissionBonus | No | Commission Bonus Amount | |
| cost | No | Service Cost | |
| crossSaleGroup | No | Cross-Sale Group | |
| description | No | Service Description | |
| displayName | Yes | Service Display Name | |
| externalData | No | External Data Key-Value Pairs | |
| externalId | No | External Service ID | |
| hours | No | Service Hours | |
| isLabor | No | Is Labor Service | |
| memberPrice | No | Service Member Price | |
| paysCommission | No | Pays Commission | |
| price | No | Service Price | |
| recommendationIds | No | Array of Recommendation IDs | |
| soldByCommission | No | Commission Percentage | |
| source | No | Service Source | |
| taxable | No | Is Taxable | |
| tenant | Yes | Format - int64. Tenant ID | |
| upgradeIds | No | Array of Upgrade IDs | |
| warrantyDescription | No | Warranty Description | |
| warrantyDuration | No | Warranty Duration |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
services_deleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Id of the SKU you are deleting | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
services_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| externalDataApplicationGuid | No | Format - guid. Items that are created with a specific guid, could be fetched/updated/removed only when the same application guid is provided. | |
| id | Yes | Format - int64. The id of the service you are requesting | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
services_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| externalDataApplicationGuid | No | Format - guid. Items that are created with a specific guid, could be fetched/updated/removed only when the same application guid is provided | |
| externalDataKey | No | Allows filtering by external data key | |
| externalDataValues | No | Allows filtering by external data values | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Code, DisplayName, CreatedOn, ModifiedOn, Price, MemberPrice, AddOnPrice, AddOnMemberPrice, MaterialsCost, PrimaryVendor, Cost, Manufacturer, Priority. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
services_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Unique id for the SKU is modified | |
| payload | Yes | Request Body | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suppressions_addD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to suppress | ||
| group_id | No | The suppression group ID | |
| reason | No | Reason for suppression | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suppressions_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Format - email. | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suppressions_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| includeTotal | No | Whether total count should be returned | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suppressions_removeD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TagTypes_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | ||
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tasks_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| assignedToId | No | ID of the person the task is assigned to | |
| businessUnitId | No | Business unit ID | |
| completeBy | No | Date the task should be completed by | |
| createdOn | No | Date the task was created | |
| customerId | No | Customer ID | |
| customerName | No | Customer name | |
| description | No | Description of the task | |
| descriptionModifiedBy | No | User who modified the description | |
| descriptionModifiedOn | No | Date the description was last modified | |
| employeeTaskResolutionId | No | Employee task resolution ID | |
| employeeTaskSourceId | No | Employee task source ID | |
| employeeTaskTypeId | No | Employee task type ID | |
| involvedEmployeeIdList | No | List of involved employee IDs | |
| isClosed | No | Whether the task is closed | |
| jobId | No | Job ID | |
| jobNumber | No | Job number | |
| modifiedOn | No | Date the task was last modified | |
| name | Yes | Name of the task | |
| priority | No | Priority of the task | |
| projectId | No | Project ID | |
| refundIssued | No | Refund issued amount | |
| reportedById | No | ID of the person who reported the task | |
| reportedDate | No | Date the task was reported | |
| startedOn | No | Date the task was started on | |
| status | No | Status of the task | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tasks_create_subtaskD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| payload | No | Subtask Details | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tasks_get_taskD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Task ID | |
| includeSubtasks | No | Include Subtasks | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tasks_get_tasksD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Values: [True, Any, False] | |
| assignedToId | No | Format - int64. Assigned to Id | |
| businessUnitIds | No | Business Unit Ids (comma separated Ids) | |
| completeBefore | No | Format - date-time (as date-time in RFC3339). Completed Before | |
| completeOnOrAfter | No | Format - date-time (as date-time in RFC3339). Completed On or After | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Created date before | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Created date on or after | |
| customerId | No | Format - int64. Customer Id | |
| employeeTaskResolutionIds | No | EmployeeTaskResolution Ids (comma separated Ids) | |
| employeeTaskSourceIds | No | EmployeeTaskSource Ids (comma separated Ids) | |
| employeeTaskTypeIds | No | EmployeeTaskType Ids (comma separated Ids) | |
| ids | No | Task Ids (comma separated Ids) | |
| includeSubtasks | No | Include Subtasks | |
| includeTotal | No | Whether total count should be returned | |
| involvedEmployeeIdList | No | Involved Employee Ids (comma separated Ids) | |
| isClosed | No | Is Closed This property is deprecated. Use Statuses instead. | |
| jobId | No | Format - int64. Job Id | |
| jobNumber | No | Job Number | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Modified date before | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Modified date on or after | |
| name | No | Name | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| priorities | No | Priorities (comma separated values) | |
| projectId | No | Format - int64. Project Id | |
| reportedBefore | No | Format - date-time (as date-time in RFC3339). Reported date before | |
| reportedById | No | Format - int64. Reported By Id | |
| reportedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Reported On or After | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, CreatedOn, DescriptionModifiedOn, CompletedBy, Priority | |
| statuses | No | Task Status | |
| taskNumber | No | Format - int64. Task Number | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tax_zones_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). | |
| ids | No | Tax Zone Ids to pull tax zones for | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, Name, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
team_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Is the team active? | |
| name | Yes | Team Name | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
team_deleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Team_GetD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
team_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeInactive | No | Whether to include inactive teams | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, CreatedOn, ModifiedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
technician_rating_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Job ID (int64) | |
| technicianId | Yes | Technician ID (int64) | |
| tenant | Yes | Tenant ID (int64) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
technicians_AccountActionsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
technicians_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
technicians_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
technicians_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| name | No | Filters records by name (case-insensitive 'contains' operation) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID | |
| userIds | No | Perform lookup by multiple User Ids (maximum 50) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
technician_shifts_bulk_deleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| deletedIds | No | Array of technician shift IDs to delete | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TechnicianShifts_CreateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Is shift active? | |
| end | Yes | Shift end time | |
| note | No | Shift note | |
| shiftType | No | Shift type | |
| start | Yes | Shift start time | |
| technicianId | Yes | Technician ID | |
| tenant | Yes | Format - int64. Tenant ID | |
| timesheetCodeId | No | Timesheet code ID | |
| title | No | Shift title |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TechnicianShifts_DeleteD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. The technician shift Id to delete | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
technician_shifts_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
technician_shifts_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| endsOnOrBefore | No | Format - date-time (as date-time in RFC3339). When the End of shift should be at or before | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| noteContains | No | Text that must appear in the Note | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| shiftType | No | Value to match ShiftType to Values: [Normal, OnCall, TimeOff] | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, CreatedOn, ModifiedOn. | |
| startsOnOrAfter | No | Format - date-time (as date-time in RFC3339). When the Start of shift should be at or after | |
| technicianId | No | Format - int64. Unique Id of technician shift must apply to | |
| tenant | Yes | Format - int64. Tenant ID | |
| titleContains | No | Text that must appear in the Title |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
technician_shifts_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Active | |
| end | No | End Time | |
| id | Yes | Format - int64. | |
| note | No | Note | |
| shiftType | No | Shift Type | |
| start | No | Start Time | |
| technicianId | No | Technician ID | |
| tenant | Yes | Format - int64. Tenant ID | |
| timesheetCodeId | No | Timesheet Code ID | |
| title | No | Title |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
technicians_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| payload | No | Payload for the update | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TimesheetCodes_GetD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. The timesheet code ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
timesheetcodes_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
timesheets_create_job_timesheetD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes | Format - int64. The job ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
timesheets_getjobtimesheetsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| endedOn | No | Format - date-time (as date-time in RFC3339). Return items having dispatch, arrive, cancel or done dates before certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| job | Yes | Format - int64. | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| startedOn | No | Format - date-time (as date-time in RFC3339). Return items having dispatch, arrive, cancel or done dates after certain date/time (in UTC) | |
| technicianId | No | Format - int64. The technician ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
timesheets_getjobtimesheetsbyjobsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| endedOn | No | Format - date-time (as date-time in RFC3339). Return items having dispatch, arrive, cancel or done dates before certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| jobIds | No | ||
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| startedOn | No | Format - date-time (as date-time in RFC3339). Return items having dispatch, arrive, cancel or done dates after certain date/time (in UTC) | |
| technicianId | No | Format - int64. The technician ID | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Timesheets_GetNonJobTimesheetsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| employeeId | No | Format - int64. The employee ID | |
| employeeType | No | The employee type Values: [Technician, Employee] | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
timesheets_update_job_timesheetD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. The job timesheet ID | |
| job | Yes | Format - int64. The job ID | |
| payload | No | The timesheet data to update | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transfers_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| batchId | No | Format - int64. Batch filter | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| customFields.Fields | No | Collection of custom field pairs (name, value) to filter by | |
| customFields.Operator | No | Can be "Or" or "And"\nValues: [And, Or] | |
| dateBefore | No | Format - date-time (as date-time in RFC3339). Return transfers with date before certain date/time | |
| dateOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return transfers with date on or after certain date/time | |
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| externalDataKey | No | Performs lookup by external data key, 'externalDataValues' must also be provided. | |
| externalDataValues | No | Performs lookup by external data values (maximum 50), 'externalDataKey' must also be provided. | |
| fromLocationIds | No | Filter by a collection of From field locations | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| number | No | Number filter | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| referenceNumber | No | Reference number filter | |
| sort | No | Applies sorting by the specified field:\n"?sort=+FieldName" for ascending order,\n"?sort=-FieldName" for descending order.\n\nAvailable fields are: Id, ModifiedOn, CreatedOn. | |
| statuses | No | Filter by a collection of statuses | |
| syncStatuses | No | Filter by a collection of sync statuses | |
| tenant | Yes | Format - int64. Tenant ID | |
| toLocationIds | No | Filter by a collection of To field locations | |
| transferTypeIds | No | Filter by a collection of transfer types |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transfers_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Transfer Id | |
| payload | No | Payload to update transfer | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transfers_update_custom_fieldsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| custom_fields | Yes | Custom fields to update | |
| tenant | Yes | Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trucks_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| externalDataKey | No | Performs lookup by external data key, 'externalDataValues' must also be provided. | |
| externalDataValues | No | Performs lookup by external data values (maximum 50), 'externalDataKey' must also be provided. | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trucks_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Truck Id | |
| payload | No | Truck details to update | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
user_roles_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| employeeType | No | Filter roles by employee type Values: [None, Employee, Technician, All] | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| name | No | Filters records by name (case-insensitive 'contains' operation) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vendors_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vendors_get_by_idD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| externalDataKey | No | Performs lookup by external data key, 'externalDataValues' must also be provided. | |
| externalDataValues | No | Performs lookup by external data values (maximum 50), 'externalDataKey' must also be provided. | |
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vendors_GetListD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| externalDataKey | No | Performs lookup by external data key, 'externalDataValues' must also be provided. | |
| externalDataValues | No | Performs lookup by external data values (maximum 50), 'externalDataKey' must also be provided. | |
| ids | No | Ids to filter by | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vendors_UpdateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Vendor Id | |
| payload | No | Vendor properties to update | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
warehouses_get_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| externalDataApplicationGuid | No | Format - guid. If this guid is provided, external data corresponding to this application guid will be returned. | |
| externalDataKey | No | Performs lookup by external data key, 'externalDataValues' must also be provided. | |
| externalDataValues | No | Performs lookup by external data values (maximum 50), 'externalDataKey' must also be provided. | |
| ids | No | Perform lookup by multiple IDs (maximum 50) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, ModifiedOn, CreatedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
warehouses_updateD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. Warehouse Id | |
| payload | No | The request body | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_booking_attributions_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Tenant ID (int64) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_lead_form_attributions_createD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tenant | Yes | Tenant ID (int64) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zone_getD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Format - int64. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zone_getlistD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | What kind of items should be returned (only active items will be returned by default) Values: [True, Any, False] | |
| createdBefore | No | Format - date-time (as date-time in RFC3339). Return items created before certain date/time (in UTC) | |
| createdOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items created on or after certain date/time (in UTC) | |
| includeTotal | No | Whether total count should be returned | |
| modifiedBefore | No | Format - date-time (as date-time in RFC3339). Return items modified before certain date/time (in UTC) | |
| modifiedOnOrAfter | No | Format - date-time (as date-time in RFC3339). Return items modified on or after certain date/time (in UTC) | |
| page | No | Format - int32. The logical number of page to return, starting from 1 | |
| pageSize | No | Format - int32. How many records to return (50 by default) | |
| sort | No | Applies sorting by the specified field: "?sort=+FieldName" for ascending order, "?sort=-FieldName" for descending order. Available fields are: Id, CreatedOn, ModifiedOn. | |
| tenant | Yes | Format - int64. Tenant ID |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
454 tool updates
v1.0.0- Removed
activities_controllers_get - Removed
activities_controllers_get_list - Removed
activity_categories_get - Removed
activity_codes_get - Removed
activity_codes_get_list - Removed
activity_types_get - Removed
activity_types_get_list - Removed
activitycategories_getlist - Removed
adjustments_get_list - Removed
adjustments_update - Removed
Adjustments_UpdateCustomFields - Removed
ap_credits_markasexported - Removed
ap_payments_get_list - Removed
ApCredits_GetList - Removed
ApPayments_MarkAsExported - Removed
appointment_assignments_get_list - Removed
appointment_assignments_unassign_technicians - Removed
AppointmentAssignments_AssignTechnicians - Removed
appointments_add - Removed
appointments_confirm - Removed
appointments_delete - Removed
appointments_get - Removed
appointments_getlist - Removed
appointments_hold - Removed
appointments_remove_hold - Removed
appointments_removeconfirmation - Removed
appointments_reschedule - Removed
appointments_update_special_instructions - Removed
arrival_windows_create - Removed
arrival_windows_get_configuration - Removed
arrival_windows_get_list - Removed
arrival_windows_update - Removed
arrival_windows_updated_configuration - Removed
ArrivalWindows_Activated - Removed
ArrivalWindows_Get - Removed
attributed_leads_get - Removed
booking_provider_tags_get - Removed
booking_provider_tags_get_list - Removed
booking_provider_tags_update - Removed
BookingProviderTags_Create - Removed
bookings_create - Removed
bookings_create_contact - Removed
bookings_get - Removed
bookings_get_contact_list2 - Removed
bookings_get_for_provider - Removed
bookings_getcontactlist - Removed
bookings_getlist - Removed
Bookings_GetList2 - Removed
bookings_update - Removed
bookings_updatebookingcontact - Removed
bulk_tags_add_tags - Removed
bulk_tags_remove_tags - Removed
business_hour_get_list - Removed
business_units_get - Removed
business_units_get_list - Removed
business_units_update - Removed
BusinessHour_Create - Removed
call_reasons_get - Removed
calls_calls - Removed
calls_get_calls - Removed
calls_get_voice_mail - Removed
calls_getdetails - Removed
calls_getrecording - Removed
calls_update - Removed
campaign_categories_create - Removed
campaign_categories_get - Removed
campaign_categories_get_list - Removed
campaign_categories_update - Removed
campaign_costs_create - Removed
campaign_costs_get - Removed
campaign_costs_get_list - Removed
campaign_costs_update - Removed
campaigns_create - Removed
campaigns_get - Removed
campaigns_get_list - Removed
campaigns_getcosts - Removed
campaigns_update - Removed
capacity_getlist - Removed
CapacityAwarenessWarning_Get - Removed
categories_create - Removed
categories_delete - Removed
categories_get - Removed
categories_get_list - Removed
categories_update - Removed
client_side_data_get - Removed
client_specific_pricing_get_all_rate_sheets - Removed
client_specific_pricing_update_rate_sheet - Removed
contact_methods_create_contact_method - Removed
contact_methods_DeleteContactMethod - Removed
contact_methods_get_contact_method - Removed
contact_methods_update_contact_method - Removed
contact_methods_upsert_contact_method - Removed
ContactMethods_GetContactMethods - Removed
contacts_create - Removed
contacts_create_contact_relationship - Removed
contacts_deletecontact - Removed
contacts_deletecontactrelationship - Removed
contacts_get - Removed
contacts_get_by_relationship_id - Removed
contacts_get_list - Removed
contacts_getcontactrelationship_list - Removed
contacts_replace - Removed
contacts_update - Removed
customer_memberships_create - Removed
customer_memberships_get - Removed
customer_memberships_get_custom_fields - Removed
customer_memberships_get_list - Removed
customer_memberships_get_status_changes - Removed
CustomerMemberships_Update - Removed
customers_create - Removed
customers_create_note - Removed
customers_create_tag - Removed
customers_createcontact - Removed
customers_delete_contact - Removed
customers_delete_note - Removed
customers_delete_tag - Removed
customers_get - Removed
customers_get_contact_list - Removed
customers_get_custom_field_types - Removed
customers_get_modified_contacts_list - Removed
customers_getlist - Removed
customers_getnotes - Removed
customers_update - Removed
discount_and_fees_get - Removed
discount_and_fees_GetList - Removed
discount_and_fees_update - Removed
DiscountAndFees_Create - Removed
DiscountAndFees_Delete - Removed
dynamic_value_sets_get_dynamic_set - Removed
employees_accountactions - Removed
employees_create - Removed
employees_get - Removed
employees_get_list - Removed
Employees_Update - Removed
equipment_delete - Removed
equipment_get - Removed
equipment_get_list - Removed
equipment_update - Removed
estimates_create - Removed
estimates_delete_item - Removed
estimates_dismiss - Removed
estimates_export_estimates - Removed
estimates_get - Removed
estimates_get_items - Removed
estimates_getlist - Removed
estimates_put_item - Removed
estimates_sell - Removed
estimates_unsell - Removed
estimates_update - Removed
export_activities - Removed
Export_ActivityCategories - Removed
export_activitycodes - Removed
export_adjustments - Removed
export_appointment_assignments - Removed
export_appointments - Removed
export_bookings_get - Removed
export_business_units - Removed
export_calls - Removed
export_contacts_customers_contacts - Removed
export_customers_get_customers - Removed
export_employees - Removed
export_equipment - Removed
export_export_installed_equipment - Removed
Export_GrossPayItems - Removed
export_inventory_bills - Removed
export_invoice_items - Removed
export_invoices - Removed
Export_InvoiceTemplates - Removed
export_job_cancel_reasons - Removed
export_job_splits - Removed
Export_JobHistory - Removed
export_jobnotes - Removed
export_jobs - Removed
export_leads_leads - Removed
export_location_recurring_service_events - Removed
export_location_recurring_services - Removed
export_locations_locations - Removed
export_materials - Removed
export_memberships - Removed
Export_MembershipStatusChanges - Removed
Export_MembershipTypes - Removed
export_payments - Removed
export_payrolladjustments - Removed
Export_PayrollSettings - Removed
Export_ProjectNotes - Removed
export_projects - Removed
export_purchase_orders - Removed
export_recurring_service_types - Removed
export_returns - Removed
export_service_agreements - Removed
export_services - Removed
export_tagtypes - Removed
export_technicians - Removed
export_timesheetcodes - Removed
Export_Timesheets - Removed
export_transfers - Removed
exportcontacts_locationscontacts - Removed
external_call_attributions_create - Removed
form_getforms - Removed
form_submission_get_form_submissions - Removed
gl_accounts_get_type_list - Removed
gl_accounts_update_account - Removed
glaccounts_createaccount - Removed
GlAccounts_GetAccount - Removed
GlAccounts_GetList - Removed
gps_create - Removed
gross_pay_items_delete - Removed
gross_pay_items_update - Removed
GrossPayItems_Create - Removed
GrossPayItems_GetList - Removed
images_get - Removed
images_post - Removed
installed_equipment_create - Removed
installed_equipment_get_list - Removed
installed_equipment_get2 - Removed
installed_equipment_post_attachment - Removed
installed_equipment_update - Removed
InstalledEquipment_Get - Removed
inventory_bills_get_custom_field_types - Removed
inventory_bills_get_list - Removed
inventory_bills_mark_as_exported - Removed
inventory_bills_update_custom_fields - Removed
invoice_templates_create - Removed
invoice_templates_get - Removed
invoice_templates_update - Removed
Invoices_CreateAdjustmentInvoice - Removed
invoices_delete_invoice_item - Removed
invoices_getcustomfieldtypes - Removed
invoices_getlist - Removed
invoices_markasexported - Removed
invoices_update_custom_fields - Removed
invoices_update_invoice_items - Removed
invoices_updateinvoice - Removed
job_cancel_reasons_get_list - Removed
job_hold_reasons_get - Removed
job_splits_get_list - Removed
job_splits_get_list_by_jobs - Removed
job_types_get - Removed
jobs_cancel - Removed
jobs_complete - Removed
jobs_create - Removed
jobs_create_attachment - Removed
jobs_create_message - Removed
jobs_create_note - Removed
jobs_get - Removed
jobs_get_attachment - Removed
jobs_get_booked_log - Removed
jobs_get_cancel_reasons - Removed
jobs_get_custom_field_types - Removed
jobs_get_job_attachments - Removed
jobs_get_job_canceled_logs - Removed
jobs_get_list - Removed
jobs_gethistory - Removed
jobs_getnotes - Removed
jobs_hold - Removed
jobs_remove_cancellation - Removed
jobs_update - Removed
JobTypes_Create - Removed
jobtypes_getlist - Removed
jobtypes_update - Removed
journal_entries_get_details - Removed
journal_entries_get_list - Removed
journal_entries_get_summary - Removed
journal_entries_sync_update - Removed
journal_entries_update - Removed
leads_create - Removed
leads_create_follow_up - Removed
leads_create_note - Removed
leads_dismiss - Removed
leads_get - Removed
Leads_GetList - Removed
leads_getnotes - Removed
leads_submitLeadForm - Removed
leads_update - Removed
location_labor_type_get_list_by_locations - Removed
location_recurring_service_events_get_list - Removed
location_recurring_service_events_mark_complete - Removed
location_recurring_service_events_mark_incomplete - Removed
location_recurring_services_get - Removed
location_recurring_services_get_list - Removed
location_recurring_services_update - Removed
locations_create - Removed
locations_create_note - Removed
locations_create_tag - Removed
locations_createcontact - Removed
locations_delete_contact - Removed
locations_delete_note - Removed
locations_delete_tag - Removed
locations_get - Removed
locations_get_contact_list - Removed
locations_get_custom_field_types - Removed
locations_get_list - Removed
locations_getlocationscontactslist - Removed
locations_getnotes - Removed
locations_update - Removed
locations_update_contact - Removed
materials_create - Removed
materials_delete - Removed
materials_get - Removed
materials_get_cost_types - Removed
materials_get_list - Removed
materials_update - Removed
materialsmarkup_create - Removed
materialsmarkup_get - Removed
materialsmarkup_getlist - Removed
materialsmarkup_update - Removed
membership_types_get - Removed
membership_types_get_discounts_list - Removed
membership_types_get_duration_billing_list - Removed
membership_types_get_list - Removed
membership_types_get_recurring_service_items - Removed
non_job_appointments_delete - Removed
non_job_appointments_get_list - Removed
NonJobAppointments_Create - Removed
NonJobAppointments_Get - Removed
NonJobAppointments_Update - Removed
opt_in_out_create_opt_out_list - Removed
opt_in_out_get_all_opt_outs - Removed
OptInOut_GetOptOutList - Removed
payment_terms_get_payment_term_model - Removed
payment_types_GetList - Removed
payments_create - Removed
payments_get_custom_field_types - Removed
payments_get_list - Removed
payments_update - Removed
Payments_UpdateCustomFields - Removed
Payments_UpdateStatus - Removed
paymentterms_getlist - Removed
PaymentTypes_Get - Removed
payroll_adjustments_get - Removed
PayrollAdjustments_Create - Removed
PayrollAdjustments_GetList - Removed
payrolls_get_technician_payrolls - Removed
Payrolls_GetEmployeePayrolls - Removed
Payrolls_GetList - Removed
PayrollSettings_GetEmployeePayrollSettings - Removed
PayrollSettings_GetPayrollSettingsList - Removed
PayrollSettings_GetTechnicianPayrollSettings - Removed
PayrollSettings_UpdateEmployeePayrollSettings - Removed
PayrollSettings_UpdateTechnicianPayrollSettings - Removed
performance_get - Removed
pricebookbulk_create - Removed
pricebookbulk_update - Removed
project_sub_statuses_get_list - Removed
project_substatuses_get - Removed
project_types_get - Removed
project_types_get_list - Removed
projects_attach_job - Removed
projects_create - Removed
projects_create_message - Removed
projects_create_note - Removed
projects_detach_job - Removed
projects_get - Removed
projects_get_custom_field_types - Removed
projects_get_list - Removed
projects_get_notes - Removed
projects_update - Removed
ProjectStatuses_Get - Removed
ProjectStatuses_GetList - Removed
purchase_order_types_update - Removed
purchase_orders_approve_request - Removed
purchase_orders_cancel - Removed
purchase_orders_create - Removed
purchase_orders_get_by_id - Removed
purchase_orders_get_list - Removed
purchase_orders_getrequests - Removed
purchase_orders_markup_delete - Removed
purchase_orders_markup_get - Removed
purchase_orders_markup_get_by_id - Removed
purchase_orders_update - Removed
PurchaseOrders_RejectRequest - Removed
PurchaseOrdersMarkup_Create - Removed
PurchaseOrdersMarkup_Update - Removed
PurchaseOrderTypes_Create - Removed
PurchaseOrderTypes_GetList - Removed
receipts_cancelreceipts - Removed
receipts_create_receipt - Removed
receipts_getlist - Removed
receipts_update_custom_fields - Removed
recurring_service_types_get - Removed
recurring_service_types_get_list - Removed
report_category_reports_get_data - Removed
report_category_reports_get_reports - Removed
ReportCategories_GetCategories - Removed
ReportCategoryReports_Get - Removed
return_types_create - Removed
return_types_get_list - Removed
return_types_update - Removed
returns_cancel - Removed
returns_create_return - Removed
returns_getlist - Removed
returns_update - Removed
returns_update_custom_fields - Removed
reviews - Removed
scheduled_job_attributions_create - Removed
scheduler_scheduler_performance - Removed
scheduler_schedulers - Removed
scheduler_schedulersessions - Removed
service_agreements_get - Removed
ServiceAgreements_GetList - Removed
services_create - Removed
services_delete - Removed
services_get - Removed
services_getlist - Removed
services_update - Removed
suppressions_add - Removed
suppressions_get - Removed
suppressions_getlist - Removed
suppressions_remove - Removed
TagTypes_GetList - Removed
tasks_create - Removed
tasks_create_subtask - Removed
tasks_get_task - Removed
tasks_get_tasks - Removed
tax_zones_get_list - Removed
team_create - Removed
team_delete - Removed
Team_Get - Removed
team_get_list - Removed
technician_rating_update - Removed
technician_shifts_bulk_delete - Removed
technician_shifts_get - Removed
technician_shifts_get_list - Removed
technician_shifts_update - Removed
technicians_AccountActions - Removed
technicians_create - Removed
technicians_get - Removed
technicians_get_list - Removed
technicians_update - Removed
TechnicianShifts_Create - Removed
TechnicianShifts_Delete - Removed
TimesheetCodes_Get - Removed
timesheetcodes_getlist - Removed
timesheets_create_job_timesheet - Removed
timesheets_getjobtimesheets - Removed
timesheets_getjobtimesheetsbyjobs - Removed
Timesheets_GetNonJobTimesheets - Removed
timesheets_update_job_timesheet - Removed
transfers_getlist - Removed
transfers_update - Removed
transfers_update_custom_fields - Removed
Trucks_GetList - Removed
trucks_update - Removed
user_roles_get_list - Removed
vendors_create - Removed
vendors_get_by_id - Removed
Vendors_GetList - Removed
Vendors_Update - Removed
warehouses_get_list - Removed
warehouses_update - Removed
web_booking_attributions_create - Removed
web_lead_form_attributions_create - Removed
zone_get - Removed
zone_getlist
454 tool updates
- First observed
activities_controllers_get - First observed
activities_controllers_get_list - First observed
activity_categories_get - First observed
activity_codes_get - First observed
activity_codes_get_list - First observed
activity_types_get - First observed
activity_types_get_list - First observed
activitycategories_getlist - First observed
adjustments_get_list - First observed
adjustments_update - First observed
Adjustments_UpdateCustomFields - First observed
ap_credits_markasexported - First observed
ap_payments_get_list - First observed
ApCredits_GetList - First observed
ApPayments_MarkAsExported - First observed
appointment_assignments_get_list - First observed
appointment_assignments_unassign_technicians - First observed
AppointmentAssignments_AssignTechnicians - First observed
appointments_add - First observed
appointments_confirm - First observed
appointments_delete - First observed
appointments_get - First observed
appointments_getlist - First observed
appointments_hold - First observed
appointments_remove_hold - First observed
appointments_removeconfirmation - First observed
appointments_reschedule - First observed
appointments_update_special_instructions - First observed
arrival_windows_create - First observed
arrival_windows_get_configuration - First observed
arrival_windows_get_list - First observed
arrival_windows_update - First observed
arrival_windows_updated_configuration - First observed
ArrivalWindows_Activated - First observed
ArrivalWindows_Get - First observed
attributed_leads_get - First observed
booking_provider_tags_get - First observed
booking_provider_tags_get_list - First observed
booking_provider_tags_update - First observed
BookingProviderTags_Create - First observed
bookings_create - First observed
bookings_create_contact - First observed
bookings_get - First observed
bookings_get_contact_list2 - First observed
bookings_get_for_provider - First observed
bookings_getcontactlist - First observed
bookings_getlist - First observed
Bookings_GetList2 - First observed
bookings_update - First observed
bookings_updatebookingcontact - First observed
bulk_tags_add_tags - First observed
bulk_tags_remove_tags - First observed
business_hour_get_list - First observed
business_units_get - First observed
business_units_get_list - First observed
business_units_update - First observed
BusinessHour_Create - First observed
call_reasons_get - First observed
calls_calls - First observed
calls_get_calls - First observed
calls_get_voice_mail - First observed
calls_getdetails - First observed
calls_getrecording - First observed
calls_update - First observed
campaign_categories_create - First observed
campaign_categories_get - First observed
campaign_categories_get_list - First observed
campaign_categories_update - First observed
campaign_costs_create - First observed
campaign_costs_get - First observed
campaign_costs_get_list - First observed
campaign_costs_update - First observed
campaigns_create - First observed
campaigns_get - First observed
campaigns_get_list - First observed
campaigns_getcosts - First observed
campaigns_update - First observed
capacity_getlist - First observed
CapacityAwarenessWarning_Get - First observed
categories_create - First observed
categories_delete - First observed
categories_get - First observed
categories_get_list - First observed
categories_update - First observed
client_side_data_get - First observed
client_specific_pricing_get_all_rate_sheets - First observed
client_specific_pricing_update_rate_sheet - First observed
contact_methods_create_contact_method - First observed
contact_methods_DeleteContactMethod - First observed
contact_methods_get_contact_method - First observed
contact_methods_update_contact_method - First observed
contact_methods_upsert_contact_method - First observed
ContactMethods_GetContactMethods - First observed
contacts_create - First observed
contacts_create_contact_relationship - First observed
contacts_deletecontact - First observed
contacts_deletecontactrelationship - First observed
contacts_get - First observed
contacts_get_by_relationship_id - First observed
contacts_get_list - First observed
contacts_getcontactrelationship_list - First observed
contacts_replace - First observed
contacts_update - First observed
customer_memberships_create - First observed
customer_memberships_get - First observed
customer_memberships_get_custom_fields - First observed
customer_memberships_get_list - First observed
customer_memberships_get_status_changes - First observed
CustomerMemberships_Update - First observed
customers_create - First observed
customers_create_note - First observed
customers_create_tag - First observed
customers_createcontact - First observed
customers_delete_contact - First observed
customers_delete_note - First observed
customers_delete_tag - First observed
customers_get - First observed
customers_get_contact_list - First observed
customers_get_custom_field_types - First observed
customers_get_modified_contacts_list - First observed
customers_getlist - First observed
customers_getnotes - First observed
customers_update - First observed
discount_and_fees_get - First observed
discount_and_fees_GetList - First observed
discount_and_fees_update - First observed
DiscountAndFees_Create - First observed
DiscountAndFees_Delete - First observed
dynamic_value_sets_get_dynamic_set - First observed
employees_accountactions - First observed
employees_create - First observed
employees_get - First observed
employees_get_list - First observed
Employees_Update - First observed
equipment_delete - First observed
equipment_get - First observed
equipment_get_list - First observed
equipment_update - First observed
estimates_create - First observed
estimates_delete_item - First observed
estimates_dismiss - First observed
estimates_export_estimates - First observed
estimates_get - First observed
estimates_get_items - First observed
estimates_getlist - First observed
estimates_put_item - First observed
estimates_sell - First observed
estimates_unsell - First observed
estimates_update - First observed
export_activities - First observed
Export_ActivityCategories - First observed
export_activitycodes - First observed
export_adjustments - First observed
export_appointment_assignments - First observed
export_appointments - First observed
export_bookings_get - First observed
export_business_units - First observed
export_calls - First observed
export_contacts_customers_contacts - First observed
export_customers_get_customers - First observed
export_employees - First observed
export_equipment - First observed
export_export_installed_equipment - First observed
Export_GrossPayItems - First observed
export_inventory_bills - First observed
export_invoice_items - First observed
export_invoices - First observed
Export_InvoiceTemplates - First observed
export_job_cancel_reasons - First observed
export_job_splits - First observed
Export_JobHistory - First observed
export_jobnotes - First observed
export_jobs - First observed
export_leads_leads - First observed
export_location_recurring_service_events - First observed
export_location_recurring_services - First observed
export_locations_locations - First observed
export_materials - First observed
export_memberships - First observed
Export_MembershipStatusChanges - First observed
Export_MembershipTypes - First observed
export_payments - First observed
export_payrolladjustments - First observed
Export_PayrollSettings - First observed
Export_ProjectNotes - First observed
export_projects - First observed
export_purchase_orders - First observed
export_recurring_service_types - First observed
export_returns - First observed
export_service_agreements - First observed
export_services - First observed
export_tagtypes - First observed
export_technicians - First observed
export_timesheetcodes - First observed
Export_Timesheets - First observed
export_transfers - First observed
exportcontacts_locationscontacts - First observed
external_call_attributions_create - First observed
form_getforms - First observed
form_submission_get_form_submissions - First observed
gl_accounts_get_type_list - First observed
gl_accounts_update_account - First observed
glaccounts_createaccount - First observed
GlAccounts_GetAccount - First observed
GlAccounts_GetList - First observed
gps_create - First observed
gross_pay_items_delete - First observed
gross_pay_items_update - First observed
GrossPayItems_Create - First observed
GrossPayItems_GetList - First observed
images_get - First observed
images_post - First observed
installed_equipment_create - First observed
installed_equipment_get_list - First observed
installed_equipment_get2 - First observed
installed_equipment_post_attachment - First observed
installed_equipment_update - First observed
InstalledEquipment_Get - First observed
inventory_bills_get_custom_field_types - First observed
inventory_bills_get_list - First observed
inventory_bills_mark_as_exported - First observed
inventory_bills_update_custom_fields - First observed
invoice_templates_create - First observed
invoice_templates_get - First observed
invoice_templates_update - First observed
Invoices_CreateAdjustmentInvoice - First observed
invoices_delete_invoice_item - First observed
invoices_getcustomfieldtypes - First observed
invoices_getlist - First observed
invoices_markasexported - First observed
invoices_update_custom_fields - First observed
invoices_update_invoice_items - First observed
invoices_updateinvoice - First observed
job_cancel_reasons_get_list - First observed
job_hold_reasons_get - First observed
job_splits_get_list - First observed
job_splits_get_list_by_jobs - First observed
job_types_get - First observed
jobs_cancel - First observed
jobs_complete - First observed
jobs_create - First observed
jobs_create_attachment - First observed
jobs_create_message - First observed
jobs_create_note - First observed
jobs_get - First observed
jobs_get_attachment - First observed
jobs_get_booked_log - First observed
jobs_get_cancel_reasons - First observed
jobs_get_custom_field_types - First observed
jobs_get_job_attachments - First observed
jobs_get_job_canceled_logs - First observed
jobs_get_list - First observed
jobs_gethistory - First observed
jobs_getnotes - First observed
jobs_hold - First observed
jobs_remove_cancellation - First observed
jobs_update - First observed
JobTypes_Create - First observed
jobtypes_getlist - First observed
jobtypes_update - First observed
journal_entries_get_details - First observed
journal_entries_get_list - First observed
journal_entries_get_summary - First observed
journal_entries_sync_update - First observed
journal_entries_update - First observed
leads_create - First observed
leads_create_follow_up - First observed
leads_create_note - First observed
leads_dismiss - First observed
leads_get - First observed
Leads_GetList - First observed
leads_getnotes - First observed
leads_submitLeadForm - First observed
leads_update - First observed
location_labor_type_get_list_by_locations - First observed
location_recurring_service_events_get_list - First observed
location_recurring_service_events_mark_complete - First observed
location_recurring_service_events_mark_incomplete - First observed
location_recurring_services_get - First observed
location_recurring_services_get_list - First observed
location_recurring_services_update - First observed
locations_create - First observed
locations_create_note - First observed
locations_create_tag - First observed
locations_createcontact - First observed
locations_delete_contact - First observed
locations_delete_note - First observed
locations_delete_tag - First observed
locations_get - First observed
locations_get_contact_list - First observed
locations_get_custom_field_types - First observed
locations_get_list - First observed
locations_getlocationscontactslist - First observed
locations_getnotes - First observed
locations_update - First observed
locations_update_contact - First observed
materials_create - First observed
materials_delete - First observed
materials_get - First observed
materials_get_cost_types - First observed
materials_get_list - First observed
materials_update - First observed
materialsmarkup_create - First observed
materialsmarkup_get - First observed
materialsmarkup_getlist - First observed
materialsmarkup_update - First observed
membership_types_get - First observed
membership_types_get_discounts_list - First observed
membership_types_get_duration_billing_list - First observed
membership_types_get_list - First observed
membership_types_get_recurring_service_items - First observed
non_job_appointments_delete - First observed
non_job_appointments_get_list - First observed
NonJobAppointments_Create - First observed
NonJobAppointments_Get - First observed
NonJobAppointments_Update - First observed
opt_in_out_create_opt_out_list - First observed
opt_in_out_get_all_opt_outs - First observed
OptInOut_GetOptOutList - First observed
payment_terms_get_payment_term_model - First observed
payment_types_GetList - First observed
payments_create - First observed
payments_get_custom_field_types - First observed
payments_get_list - First observed
payments_update - First observed
Payments_UpdateCustomFields - First observed
Payments_UpdateStatus - First observed
paymentterms_getlist - First observed
PaymentTypes_Get - First observed
payroll_adjustments_get - First observed
PayrollAdjustments_Create - First observed
PayrollAdjustments_GetList - First observed
payrolls_get_technician_payrolls - First observed
Payrolls_GetEmployeePayrolls - First observed
Payrolls_GetList - First observed
PayrollSettings_GetEmployeePayrollSettings - First observed
PayrollSettings_GetPayrollSettingsList - First observed
PayrollSettings_GetTechnicianPayrollSettings - First observed
PayrollSettings_UpdateEmployeePayrollSettings - First observed
PayrollSettings_UpdateTechnicianPayrollSettings - First observed
performance_get - First observed
pricebookbulk_create - First observed
pricebookbulk_update - First observed
project_sub_statuses_get_list - First observed
project_substatuses_get - First observed
project_types_get - First observed
project_types_get_list - First observed
projects_attach_job - First observed
projects_create - First observed
projects_create_message - First observed
projects_create_note - First observed
projects_detach_job - First observed
projects_get - First observed
projects_get_custom_field_types - First observed
projects_get_list - First observed
projects_get_notes - First observed
projects_update - First observed
ProjectStatuses_Get - First observed
ProjectStatuses_GetList - First observed
purchase_order_types_update - First observed
purchase_orders_approve_request - First observed
purchase_orders_cancel - First observed
purchase_orders_create - First observed
purchase_orders_get_by_id - First observed
purchase_orders_get_list - First observed
purchase_orders_getrequests - First observed
purchase_orders_markup_delete - First observed
purchase_orders_markup_get - First observed
purchase_orders_markup_get_by_id - First observed
purchase_orders_update - First observed
PurchaseOrders_RejectRequest - First observed
PurchaseOrdersMarkup_Create - First observed
PurchaseOrdersMarkup_Update - First observed
PurchaseOrderTypes_Create - First observed
PurchaseOrderTypes_GetList - First observed
receipts_cancelreceipts - First observed
receipts_create_receipt - First observed
receipts_getlist - First observed
receipts_update_custom_fields - First observed
recurring_service_types_get - First observed
recurring_service_types_get_list - First observed
report_category_reports_get_data - First observed
report_category_reports_get_reports - First observed
ReportCategories_GetCategories - First observed
ReportCategoryReports_Get - First observed
return_types_create - First observed
return_types_get_list - First observed
return_types_update - First observed
returns_cancel - First observed
returns_create_return - First observed
returns_getlist - First observed
returns_update - First observed
returns_update_custom_fields - First observed
reviews - First observed
scheduled_job_attributions_create - First observed
scheduler_scheduler_performance - First observed
scheduler_schedulers - First observed
scheduler_schedulersessions - First observed
service_agreements_get - First observed
ServiceAgreements_GetList - First observed
services_create - First observed
services_delete - First observed
services_get - First observed
services_getlist - First observed
services_update - First observed
suppressions_add - First observed
suppressions_get - First observed
suppressions_getlist - First observed
suppressions_remove - First observed
TagTypes_GetList - First observed
tasks_create - First observed
tasks_create_subtask - First observed
tasks_get_task - First observed
tasks_get_tasks - First observed
tax_zones_get_list - First observed
team_create - First observed
team_delete - First observed
Team_Get - First observed
team_get_list - First observed
technician_rating_update - First observed
technician_shifts_bulk_delete - First observed
technician_shifts_get - First observed
technician_shifts_get_list - First observed
technician_shifts_update - First observed
technicians_AccountActions - First observed
technicians_create - First observed
technicians_get - First observed
technicians_get_list - First observed
technicians_update - First observed
TechnicianShifts_Create - First observed
TechnicianShifts_Delete - First observed
TimesheetCodes_Get - First observed
timesheetcodes_getlist - First observed
timesheets_create_job_timesheet - First observed
timesheets_getjobtimesheets - First observed
timesheets_getjobtimesheetsbyjobs - First observed
Timesheets_GetNonJobTimesheets - First observed
timesheets_update_job_timesheet - First observed
transfers_getlist - First observed
transfers_update - First observed
transfers_update_custom_fields - First observed
Trucks_GetList - First observed
trucks_update - First observed
user_roles_get_list - First observed
vendors_create - First observed
vendors_get_by_id - First observed
Vendors_GetList - First observed
Vendors_Update - First observed
warehouses_get_list - First observed
warehouses_update - First observed
web_booking_attributions_create - First observed
web_lead_form_attributions_create - First observed
zone_get - First observed
zone_getlist
TDQS
D1.4/5.0
Disambiguation2/5
Many tools have overlapping purposes, such as multiple 'get_list' variants for the same resource (e.g., appointments_getlist vs appointments_get_list) or similar CRUD operations across different resources that could cause confusion. The lack of descriptions exacerbates this ambiguity, making it hard to distinguish between tools like 'activities_controllers_get' and 'activities_controllers_get_list' or 'export_contacts_customers_contacts' vs 'exportcontacts_locationscontacts'.
Naming Consistency2/5
Naming is highly inconsistent, mixing snake_case (e.g., 'appointments_add'), camelCase (e.g., 'Adjustments_UpdateCustomFields'), and variations like 'getlist' vs 'get_list'. There is no predictable pattern across the toolset, with some tools starting with uppercase (e.g., 'ArrivalWindows_Activated') and others with lowercase, leading to a chaotic naming scheme that hinders usability.
Tool Count1/5
With 454 tools, the count is extremely excessive for any MCP server, far beyond the typical well-scoped range of 3-15 tools. This overwhelming number suggests poor tool surface design, likely auto-generated or poorly curated, making it impractical for agents to navigate or use effectively.
Completeness4/5
Despite the excessive tool count, the server appears to cover a broad domain (ServiceTitan's business operations) with extensive CRUD and export operations across resources like appointments, customers, jobs, and invoices. There are no obvious major gaps in functionality, as most entities have create, get, update, and delete tools, but the sheer volume and lack of descriptions make it hard to assess fully.
Maintenance
ActivityInactive
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
- ZapierOAuthcom.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
- mcp-serverOAuthio.klokin
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
Related MCP Servers
- AlicenseCqualityAmaintenanceConnects AI assistants to ServiceTitan with a default catalog of 264 read-only tools for CRM, dispatch, accounting, reporting, and analytics. Supports focused discovery profiles; write operations are experimental and require explicit opt-in.264452MIT
- AlicenseAqualityCmaintenanceAn MCP server that enables AI assistants to access Sprout Social data including analytics, publishing, messages, and listening through a standardized interface.1717MIT
- AlicenseAqualityAmaintenanceAn MCP server that enables AI assistants to interact with ServiceNow instances, allowing script execution, data querying, ATF tests, and log tailing through natural language commands.8726516MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JordanDalton/ServiceTitanMcpServer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server